浅谈持续集成

读一读《持续集成 软件质量改进和风险降低之道》【1】，结合自己的经验，浅浅地总结一下自己的感悟。

看了序，理论上就知道80%，在项目中，原来的Parterner打算使用CruiseControl，结果由于项目时间问题，后来又人事变更，未能开展。（当然也可以说这都是借口，就是懒惰）在实践中除了版本管理，剩下的过程都By Hand。但是思想上还是和这比较接近，当然Automatic永远是王道。

”当我们得知大多数开发机构的自动化程度时，通常会很吃惊。开发者花了绝大部分时间为他们的用户实现自动化过程，但却没用发现将他们自己的开发过程自动化的方法...”，深有感触。

团队中是有Parterner在试图搭建，但是老是不能实战。当然在项目不大的情况下，By Hand倒是问题不是很大。这就好比吃一粒“良药”，它很苦口，服用方式基本可以是——干吞和水服。前者过程有点难受，后者很舒畅顺捷。但是后者需要准备水。同样的，”自动化“式的持续集成不是喊出来的，自动化辅助工具的搭建也是需要时间精力的。当然我绝对支持”自动化“，这才展现出程序（及程序员）的意义。其中，让过程”自动化“才是智慧的”懒惰“（看来懒惰也是分等级和智慧的），”智慧的懒才是真的懒“。

说的这么多，那么到底什么是持续集成呢？在这里请容许我”借用“从Thougthworks‘ Worker那里听来的例子，”借用“其实只是客气的说法，大家看了就知道，其实这个”案例“应该是共享的，因为大家都可能也有权利去经历，但是对现实世界的问题抽象化并给出解决方案，还是需要智慧和时间的，所以还是要感谢Thougthworks‘。

”案例“：

一个木制家具，有3大部分组成（models），由于”大“，分3组分别进行针对性的制作。在基本讨论后，于是乎分组后，各组就”轰轰烈烈“的开展工作了。3个月后，3组工作都按计划完成，现在需要合并组装——集成（integration）。这时候，他们发现3组的工作结果无法进行合并，因为型号尺寸等问题。于是，只能再分组进行”轰轰烈烈“的修改工作。然后在合并组装——集成...

这个例子告诉我们：分开开展的，然后需要集成的工作，more earlier to integrate is more better to control.

其实这里的根本问题是：

1.计划工作做不完备：完全可以详细地设计好各部分后再“”轰轰烈烈“。

2.过程交流不足：完全可以在交流中统一。

3.监管人员不"给力式“的负责：他应该是了解各组实时进行情况的。

...

你可能还可以给出很多其他的理由（和解决办法），但是最简单的实践过程，也是最方便和”懒惰“的途径，就是”直接组装“，一目了然。同时问题（及风险，可以延伸发散式的预测趋势）也暴露的很明显。一举多得的“快捷懒惰式”方法为什么不用？还去分开观察、提炼、集中思考、发现问题、反馈给各组，然后反复。人类是很cleaver的，comfortable才是首选。

同时，《人月神话》也时时刻刻地给我们敲响着警钟，”complex/huge projects"、“n^n communications”、瀑布式开发的不可行性......也就是说以上所列的“计划工作做不完备”、“过程交流不足”、“监管人员不"给力式“的负责”在实际稍大/大的项目中是无法避免的，同时他们的逆命题也是不可行的。

于是，直接、尽早的向最终结果（Or里程碑）靠近是一个“快捷懒惰式”和可行的方案。这就是“持续集成”（Continuous Integration）的思想，其次就是more process、more details、more automatically，尽可能的控制范围广，过程自动化。

当然团队式的软件项目，是团队的密切合作、交流，共同努力的结果，所以让每个成员了解“集成”的现状、结果、bug是很有必要的也是必须的，当然类似这些交流过程，也是可以自动化的（如email、SMS...）。

常规的目标过程有：源代码编译、数据库集成、测试、审查、部署、文档与反馈。还有就是加入代码标准的实行力度、代码重复率、成员出错频率...可以试想，这样的自动化过程会让工作变得多么舒适，让你拥有更多的时间"to be lazy"，说的积极些，做些其他的事情。

如果人生是一种体验，那么这个体验是有时间限制的，让一些过程自动化，可以让我们更好的体验人生。当然我也不否认你说，By Hand的过程也是体验人生。那"重复”地By Hand，你怎么看？如果你还是一样的回答，那好吧，我不再多说了，也许是我的认识错了，据说“重复地做好一件事情”是很不容易的，那这样的话，我支持你。但是我要申明“对不起，我很懒，那我就不加入你的团队了”。

下面抄自《Continuous Integration...》，”CI的价值是什么“：

”从大的方面来说，CI的价值在于：

• 减少风险。
• 减少重复过程。
• 在任何时间、任何地点生成可部署的软件。
• 增强项目的可见性。
• 对开发团队的软件产品建立起更强大的产品信心。

      ...

“【1】

最后再抄录一段，很好笑的对话：

” Joan（开发者）：......我已经将它自动化了。我写了一些批处理脚本删除并重新创建数据库中的表。

  Sue（技术负责人）：好极了。你将它提交到CVS库了吗?

  Joan：没有。

  Sue：你把它放到构建脚本中去了吗？

 Joan：没有。

 Sue：那么，如果它不是CI系统的一部分，它就没有真正实现自动化......对吗

"【1】

参考：

【1】持续集成 软件质量改进和风险降低之道.Paul M. Duvall[著].王海鹏[译].电子工业出版社.