Fork me on GitHub

黄博文的地盘

我是一个程序员.

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

| Comments

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

《持续集成》站在理论的角度阐述了持续集成能够解决什么样的问题,如何解决,需要遵循那些原则等。这本书的副标题是-软件质量改进和风险降低之道(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的代码库中、从持续集成进阶到持续交付等。这本书基本没怎么涉及这些话题,毕竟它出版有些年头了,但这仍不失为一本好书。

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

Comments