持续集成相关总结(五)

(五)持续集成的深层理解与相关问题研究

1.持续集成与敏捷编程

在敏捷领域中,测试驱动和持续集成被称为敏捷编程的两大基石,于是乎,很多人的概念里就是持续集成是为了实现敏捷编程的。这是一个错误的认识。实际上,早于敏捷编程概念的提出,持续集成作为一个best practice就已经被很多公司采用了,只不过作为一个概念,则是由Martin为了推进敏捷所倡导并由此风靡起来。持续集成本身只是一种 practice,并不被什么开发模型所限制,在任何一种开发模型中都可以采用,也可以运行得非常理想。

2.持续集成还是阶段集成

有很多人说,我不做持续集成,照样工作的很好。因为我们一个(小)阶段出一个版本,照样控制得非常好。我得恭喜你,首先持续集成也好,阶段集成也罢,你做了,做了就好,比没有做要好很多,也使你的项目管理上了轨道了。这两者之间的区别仅是频率而已。

   
那么究竟那种方式更加理想,更加符合项目的开发和管理呢?其实这个问题Steve McConnell在他那本获得Jolt大奖的书《Code Complete(代码大全)里有过回答了。他说:对于一个微型程序来说,阶段式的集成或许是最佳方法。何谓微型程序,他说就是那种两三个类的程序,而你又很走运的话,那么阶段式集成就可以是你的最佳方法了。当然,这位老兄是个老美,我们也都知道老外嘛,都比较笨一点,不会转弯一点,所以呢,他说微型程序,对于我们拥有5000年文明的中国人说,可以再扩大点吧,对于一 个小型项目,就是那种二三十个类的项目,也许使用阶段集成也不会出啥子问题吧。

3.对持续集成好处的理解

很多人肯定非常不苟同我的看法,他们认为即使没有做持续集成,甚至没有做阶段集成,但是项目一样按时的完成,甚至提前完成,而且照样完成的非常理想,老板满意,客户满意,夫复何求?而做持续集成,无非就是动不动收到一封邮件,说这个build成功了,那个build失败了,不过就是持续编译罢 了,我自己打个命令编译一下,不就知道了吗?要做个daily build,我还要颠颠的去set up,还要花力气去配置,效果也不见得好到什么地方去。

   
对于这样一些问题,我想首先我们还得搞清楚,究竟为什么我们要去做持续集成,持续集成究竟可以给我们带来什么好处。同样在《Code Complete》里提到了,对于持续集成(在书中,Steve McConnell使用Incremental Integration的术语)有以下几点好处:

易于定位错误   也就是当你的持续集成失败了,说明你新加的代码或者修改的代码引起了错误,这样你很容易的就可以知道到底是谁犯了错误,可以找谁来讨论。
及早在项目里取得系统级的成果   因为代码已经被集成起来了,所以即使整个系统还不是那么可用,但至少你和你的团队都已经可以看到它已经在那了。
改善对进度的控制,改善客户关系   这点非常明显,如果每天都在集成,当然每天都可以看到哪些功能可以使用,哪些功能还没有实现。如果你是程序员,你不用在汇报任务的时候说我完成了多少百分比而烦恼,而如果你是项目经理的话,那么你也不再烦恼程序员说完成了编码的50%到底是个什么概念。
更加充分地测试系统中的各个单元   这也是我们常讲的Daily BuildSmoke Test相结合带来的绝大好处。
能在更短的时间里建造整个系统   这点恐怕要你实施以后才能得出结论。就我们而言,持续集成并没有为每个项目都缩短时间,但却比没有实施时,项目更加可控,也更加有保证。

随着时间的推移,持续集成带来的更多好处,也逐渐被认识到了,比如说:
有助于项目的开发数据的收集   比如说,项目代码量的变化,经常出错的Tests,经常出错的source code,等等。
与其它工具结合的持续代码质量改进   如与CheckStyle, PMD, FindBugs, Fxcop等等等等的结合。
与测试工具或者框架结合的持续测试   如与xUnitSilkTest, LoadRunner等等的结合。
便于Code Review   在每个build里,我们都可以知道与前一个build之间有什么改动,然后针对这些改动,我们就可以实施Code Review了。
便于开发流程的管理   比如说,要把一个开发的build提交给测试组作测试,测完满意了,再提交到发布组去发布。

4.持续集成应该自动化什么

我们要以尽可能少的成本来获得尽可能多的价值。这就要考虑哪些自动化是必要的。Jez Humble提到至少有六点要做到自动化,它们分别是(1)自动化的运行测试;(2) 自动产生可部署的二进制成品;(3) 自动将成品自动部署到近似生产环境;(4) 自动为CodeBase打上标签;(5) 自动运行回归测试;(6)自动生成度量报告。

5.只有持续集成服务器是远远不够的

正如Jez Humble所说,CruiseControl和其它的CI工具本质上只不过是一个定时器,时间一到,做你让它做的事情。所以,必然要有其它工具与其结合,方显持续集成的本色。这些工具又是什么呢?想测试的话,你就要用一些测试工具,如JUnitJWebUnitSelenium等等;想检查代码标准的话,你就要用checkstyle等代码规范检查工具;想要了解测试覆盖率的话,你可能就要用到JCoverage啦。当然,想得到二进制文件,就要用到AntMake之类的工具啦。

6.最重要的事:实践与反思

也许这些东西大家都知道,而且有些人可能已经实践过。无论这些实践的结果是怎样的,一定不要忘记总结和反思。如果这些实践成功了,不要把它归功于这个工具,而是要总结一下为什么会成功,如果你愿意的话,还可以和大家分享一下。如果这些实践失败了,也不要把它归功于这个工具,而是要反思一下,是否正确地使用了这个工具,团队成员是否都喜欢这个工具,为什么?

7.跌跌撞撞的持续集成之路(分享持续集成经验)

    网站链接:http://cd.qq.com/a/20090910/000715.htm

posted @ 2011-10-31 12:19  天空行马  阅读(468)  评论(0编辑  收藏  举报