2019-01-04曾经参与过一个项目，中美印三地开发，开发测试产品加起来可能过百吧。当时，我们中国团队做过一个这样的工具，每次在git-review上提交/更新review时，自动构建一个当前branch是最新版，打上review的patch，然后构建，跑UT，UT覆盖率在95%再向下走。
做到这一步，其实不算什么，但是已经超过国内80%的同行水平了。然后我们还会构建一个虚拟机镜像安装这个build，安装好了在专门的虚拟测试网络上启起来，利用自动测试工具跑一些基本的case，比如登陆啊，基本的操作啊，这一系列跑完，才可以正式的让人review。
这个项目因为一些方向性和市场的问题，一年多就失败了，项目组解散。但是集成水平，的确是我经历过的最高的。展开作者回复: 确实做得不错！项目失败和实践之间是不能划等号的，不能因为项目失败就否认实践的优秀。
1 17
2019-01-04打卡：
目前我们团队借助git-flow，以git的分支 feature、release、hotfix和里程碑tag进行持续集成和构建；
release 出发测试环境构建、tag出发生产环境部署作者回复: 我最喜欢的分支模型是，没有feature分支的git flow。
7- 2019-01-04公司一部分人在美国这边做开发，另一部分在台湾做开发，每到集成，想到的头疼的问题第一个就是时差问题，一般的流程就是他们那边发现了问题邮件发给我们，我们看一下感觉好像不是这边的问题，给些解释和建议又邮件抛回去，感觉这种情况可能需要就是一方的负责人得牺牲一下自己的私人时间，积极开会沟通？持续集成必须合作的所有teams都同意，或是都有这样的意识才行，不然光靠一方的努力感觉弄不起来，不知老师如何看？
作者回复: 不仅仅是持续集成，任何涉及到协作的实践都需要协作相关方的共同配合才可能有效落地。
如果大家都觉得工作起来很辛苦，其中肯定有不对的地方，需要坐下来，一起商量解决方案。我在专栏中给大家提供的就是你坐下来可以提出的建议，比如，持续集成，验收标准等等。 5 
2019-01-04简单一句，小步快走。尽早的暴露问题并解决问题，能够减少系统潜在奉献。持续集成能够帮忙做到 5
2019-01-04关于代码提交的问题，举例子是公司要求每日提交，如果一个功能没做好也要提交？还是说只要没有编译问题，即使未完成也得提交？作者回复: 好问题，你对提交的理解说明任务分解做得不够，不能小步提交，这是在任务分解模块要讲的内容，敬请期待。
4
2019-01-12虽然我们在同一个时代写代码做开发，但在技术实践层面，不同的团队却仿佛生活在不同的年代。 3
2019-03-19开发完成的定义：集成为可运行的软件
开发模式：持续集成，尽早构建
git 版本工具，Jenkins 持续构建 2
2019-01-06今日概念：
1. 集成：将各个独立部分组合在一起使其成为一个新个体的过程；
2. 每日集成：每天进行一次集成，它和持续集成只有时间间隔上的差别；
3. 持续集成：每日集成推演到极致的结果，将开发和集成合二为一；
今日总结：
集成本身就是写代码的一个环节，持续集成已经有了很成熟的体系与实现，早点使用持续集成吧；展开 2
2019-05-05有一次为了改进我们的代码，新拉了个分支出来，在开发的过程中，新的功能要在新老两个分支上做两遍，最后合并的时候还要梳理一遍有没有只做在老的分支上的功能，还有个稍微大点的功能是国外的同事开发在老的分支上的，合并过来，太痛苦了作者回复: 我一直认为，大分支就是给自己找麻烦。后面还有关于分支的讨论。
1
2019-02-23老师，您好；最近在做流程方面的重新梳理和实践，发现有个问题：比如产品那边起初是5个功能上线，后来由于某些原因或者市场原因临时砍掉一个一个功能，而这功能按持续集成每日构建的思路代码肯定是合掉了，这就产生代码回退和重新集成的问题，这个痛点有什么好的方案吗作者回复: 在“任务分解”模块的答疑中，我介绍了 Feature Toggle，你可以了解一下。
这里面的关键点在于，你的代码模块需要划分清楚，这样无论是使用 Feature Toggle，还是调整代码，都有足够的空间去操作。 1
2019-01-16我们公司是单独一个在现在教育网站，只有UI、后端和我一个前端，后端包揽了大部分事情，我每次写代码是Git下拉代码，然后修改，修改后上传，都结束后合并到主分支，通知后端上线。请问老师这算是每日构建持续集成吗？如果不算我们公司这种情况应该怎么样才算？作者回复: 这种情况是最原始的开发状态，什么都没有。
1 1
2019-01-08持续集成不是很普通的事？作者回复: 你有这种感觉，说明你所在的公司做得不错，但行业中还有大量需要提高的公司。
1
2019-01-08没有feature分支的git flow。是指开发和测试分支都使用一个么作者回复: 你可以先了解一下git flow，去掉feature分支就变成了主干开发，这是我鼓励的，换句话说，我的观点就是尽可能不使用分支，更别说开发分支，测试分支了。
2 1
2019-01-04我很喜欢CI，改动的代码造成了什么影响，在CI里暴露出来可以快速解决。到创业公司后，我也一直在推广CI工作，希望CI能降低发现错误的成本 1
2019-10-31笔记
早点集成。
好处，早点集成，早点发现问题。
思考 未get 到其中深意，但最后集成的苦没少吃。
但有时想想，好像根源是需求把控，产品很多东西啰哩巴嗦的定不下来，往往需要靠上线这事逼他们妥协。
so 走向持续集成，是需要前序准备的。展开
2019-09-09老师，之前在一家公司开发是开发完成一部分功能，然后测试测试一部分功能，开发继续开发，并修复之前的bug,这样的做法是对的吗，因为还要处理之前的bug，可能会耽误开发的进度，还有这算持续集成的范围吗
2019-08-19请问老师，持续集成的前提是不是要有单元测试？我咨询过身边二三十个同行，要求写单元测试的公司不到20%，那是不是就无法持续集成？另外持续交付是指所有的测试工作都自动化吗，不是太理解这过程作者回复: 持续集成一定要自动化，不自动化开发速度就起不来。测试对于公司而言，就像法律，是底线，不是高标准。
2019-07-11交付一个可运行的软件也是终局思维。Effective 和 Efficiency的区别就是前者更重视结果，而后者更在意过程。
2019-05-30svn和git，写一个接口，自己测试了就提交上去，难道不是日常操作？
2019-04-18咳咳咳，郑大大你就这么鼓励小朋友们挑战BA吧，就说我们的工作沟通成本越来越多😂作者回复: 以行业的平均水准而言，这种行为确实要鼓励。