持续集成工具CruiseControl.net对软件项目过程的改善

在将CruiseControl.net(以下简称为CCNet)于2011-9-20引入我司的三个项目7**项目，2***项目，3***项目，分别为它们部署了持续集成服务器。经过3个月的实践.发现确实能够将测试及早引入项目过程，对项目进行不间断地持续集成确实对项目产生了良好的作用。

换个角度来看，CCNet也是开发者的好助手。同时，它也为整个项目的良性运作保驾护航。

一般情况下，开发者一旦完成了修改，就会在自己的计算机上启动一次 build。这会将其本地的源代码编译并生成为exe或DLL。只有当所有的 build 完成并没有任何错误时，这个 build 过程才可认为是成功的。

当开发者 build 成功后，他就可以考虑将改动提交到源码库（如VSS或SVN）。但麻烦的情况在于别的开发者可能已经在他之前修改过 源代码库中的代码mainline。这时他需要首先把别人的修改更新到他本地，再重新做 build。如果别人的代码和他的有冲突，就会在编译的过程中引起错误。他有责任改正这些问题，并重复这一过程，直到他获取代码能通过 build 并和代码库的 mainline 的代码同步。

一旦开发者本地的源代码能通过 build，并和 源代码空间的代码 同步，他就可以把他的修改提交到源码库。

然而，提交完代码不表示就完事大吉了。还要做一遍集成 build（但是在引入CCNet之前，开发者此时提交完后就停止了，他们接下来会去做别的工作；此后的问题通常过一段有限的时间后才会被发现），这次在集成计算机上并要基于源码库的 mainline 的代码。只有这次 build 成功了，开发者的修改才算告一段落。因为总有可能他忘了什么东西在自己的机器上而没有更新到源码库。只有他提交的改动被成功集成了，他的工作才算结束。这可以手工运行（引入工具之前都由测试者手工运行这次build），现在由 CCNet自动运行。

如果两个开发者的修改存在冲突，这通常会被第二个人提交代码前本地做 build 时发现。即使这时侥幸过关，接下来的集成 build 也会失败掉。不管怎样，错误都会被很快检测出来。好的团队应该每天都有多个成功的 build。错误的 build 可以出现，但必须尽快得到修复。

这样做的结果是总能得到一个稳定的软件，它可能有一些 bug，但可以正常工作。每个人都基于相同的稳定代码进行开发，而且不会离得太远。Bug被发现得越快，花在改正上的时间就越短。

在7**项目目前的代码规模下（7**在三个项目中代码规模最大），从开发者Checkin之后到CCNet发现问题后经邮件反馈出来的时间为1分47秒（在引入CCNet之前，2***项目遇到build的失败的情况时，平均要花费20分钟来解决掉这个错误，开发者一般要涉及到两到三位，测试者一位，这个小团队将离开原来的工作，在一起一直到这个错误解决）。CCNet的引入大大缩短了build失败被发现的时间。这些代码在不到2分钟之前才被一位开发者Checkin，这位开发者收到CCNet的反馈后，就可以很快能定位到问题所在并将其改掉。同时，这也将测试者从不定时遇到build失败的噩梦中拯救出来（在引入CCNet之前2***项目的测试者平均每天要遇到两次build失败）。这样就增加了整个项目的安全感。

 是的，如果你没有在一个多人项目中的经验，或者之前对持续集成没有接触(你可以参考持续集成实践之一 概念 和 持续集成实践之二 VSS+MsBuild2.0+CC.net  两篇博文)，那看以上的叙述就很不太直观。下面我们看图说话，请注意图片上的时间和标注及对图片的解释。

以2***项目为例，引入CCNet工具之前遇到build失败后的情况截图如下：

测试者：

开发者：

（请注意：这位开发者说好了的时候，并没有真正进行过集成测试，有可能是好的，但还是有可能没好，这点很像薛定谔的猫。）

CCNet进行持续集成时的截图如下：

（开发者每一次Checkin之后，ccnet即时的去打开关着薛定谔的猫的盒子的盖子，并给出确定的结果。如上图中的2011-12-19的第19,20,21次的修改都没有将第18次引入的bug解决掉，在第22次我们才再次获得了一个成功的build。这些所有的动作都是CCNet自动触发的。）

 

附：

此文引用了Martin Fowler 的《持续集成》第二版中的部分相关内容，点这里可以查看。