让你的CI跑起来-《持续集成》读书总结

持续集成已经被公认为极具价值的一项工程实践。在初始化一个项目时一个重要的任务就是搭建持续集成服务器，编写构建脚本。在我工作的所有项目中都引入了持续集成机制。它已经像氧气一样成为软件开发过程中的一项工程活动。

《持续集成》站在理论的角度阐述了持续集成能够解决什么样的问题，如何解决，需要遵循那些原则等。这本书的副标题是-软件质量改进和风险降低之道（Improving Software Quality and Reducing Risk）。副标题直指持续集成的两个好处：提高软件质量及降低项目风险。

当前面临的问题

当前软件开发一直存在两大难题：一是确定软件的需求，即确定目标。究竟软件要做成什么样子，在客户的头脑里可能是个三角形，在业务分析员的头脑中可能是个正方形，在开发者的头脑中可能是个圆形，而最终出来的产品或多或少都会给客户带来“惊喜”。

二是确定目前离目标还有好远，即确定剩余的工作量。这个问题就是项目缺少可见性的问题。当一个程序员告诉他的经理说这个功能只剩下20%的工作量时，具体指什么那？这个20%的比例是怎么得到的？是还要再花20%的时间？……

持续集成虽然解决不了第一个问题，但是关于第二个问题，持续集成向我们介绍了一种增加项目可见性，提高开发效率，降低项目失败风险的有效实践经验。

其实持续集成蕴含有哲学思想：分而治之。即我们通常说的 “滴水穿石，硅步千里”。

传统瀑布方法一般将系统集成放置到开发完成后，这样会导致一系列的问题。

没有一致的、可部署的软件。只有等到集成完成之后，我们才能够拿到一个可以使用的软件。
很晚才发现缺陷。接口不一致、接口不满足实际需求、开发人员对功能理解有偏差….这些问题在集成测试时统统暴露出来。由于软件根基已经建立，这时候修改容易伤筋动骨。
低品质的软件。正如上条所说，缺陷发现的越晚，修改的代价越大。在交付的压力下，各种猴子补丁散落在系统的各个地方，软件的品质自然也很难提高。
缺少项目可见性。直到系统集成之前，你都拿不出可用的软件。而且系统集成之时，往往是项目中最棘手、最紧张的时刻，你很难预估集成什么时候能够彻底完成。这样的项目自然谈不上什么可见性了。

CI的价值

引入了CI（Continuos Integration，即持续集成）以后，每个开发人员在提交代码的时候都会自动进行构建，包括代码审查、编译、单元测试、打包、功能测试等。这样保证了开发人员的每次提交都是安全的。打包生成的文件随时可以被测试人员拿去测试。如果需要给客户演示功能，也只需从CI服务器上直接获取指定的打包完成的文件即可。

CI的好处多多。

减少风险

缺陷的检测和修复变得更快，让寻找和修改bug的工作变简单（只修改系统一小部分，无需看太多代码。由于提交后就可以得到反馈，记忆很新鲜，可以进行差异调试。）同时过早的引入集成，使我们能更好的审视各个模块的接口是否满足要求，减少项目中的假定。

减少重复过程

由于CI将大量的工作给自动化了，那么可以让人们有时间做更多的需要动脑筋的、更高价值的工作。而且通过对重要过程自动化，克服了项目中某些成员对实现改进的抵制，有利于持续集成的推进。这样就形成了一个良性循环。

在任何时间、任何地点生成可部署的软件

对于客户来说，可以部署的软件是最实际的资产。而CI则可以轻松做到这一点。

增强项目的可见性

通过对CI服务器的监控，可以随时了解项目的趋势。CI上的红色或绿色表示了当前项目的健康程度。每一个功能的交付都经历了单元测试或集成测试的考验。

对开发团队的软件产品建立起更强大的产品信心

CI可以防止破窗综合症，让开发团队一点点积累起对产品的信息。

CI的特征

从上述图中可以看出CI有四个特征：

与版本控制系统的连接

当开发者提交代码时，就会触发CI系统的运行。

构建脚本

构建脚本继承了审查、编译、测试、打包、功能测试等环节，保证了产品的质量与可用性。

某种类型的反馈机制

集成的结果要能很容易的获取到。可以通过一个web页面来呈现，也可以给团队人员发Email。我们公司有些团队做了一些有意思的插件，比如将build的结果映射到一个灯上，或者当构建失败时播放一段音乐等，随时提醒团队成员对build的关注。

集成源代码变更的过程

代码变更会触发构建,保证了CI能够经常性的运行。

CI对团队的要求

很多团队说我们引入了持续集成，但是收到的效果并不好。比如遇到了CI持续失败、没人关注构建结果、没有及时修复build等。那是因为开发团队没有遵循一定的原则。

经常提交代码
不要提交无法构建的代码
立即修复无法集成的构建
编写自动化的开发者测试
必须通过所有测试和审查
执行私有构建
避免迁出无法构建的代码

持续集成是一个实践性很强的工程活动，其实发展到现在也遇到了一些新的挑战。比如如何减少构建时间、怎样实现分阶段分布式构建、如何应用在有Branch的代码库中、从持续集成进阶到持续交付等。这本书基本没怎么涉及这些话题，毕竟它出版有些年头了，但这仍不失为一本好书。

如果你理解了持续集成的好处，那么在应用过程中就不会有抵触心理，而且也更容易理解持续交付。