三言两语话敏捷(2) - 持续集成

这篇,我只谈“持续集成”。

有人说敏捷必须有持续集成,有人说持续集成就是敏捷。如果你还不了解持续集成,赶紧看看持续集成》第二版的中译本

持续集成的最大益处是降低风险,及时发现代码的缺陷,并让代码保持随时可用的状态。

如果不使用持续集成,会出现什么问题呢?

  1. 到最后的集成时,会花费大量的时间,而且可能有很多BUG。

  2. 开发过程会比较混乱。开发人员无法基于稳定的代码版本新增或修改代码。

一个良好的持续集成应该包括,鼓励冲突编辑的源代码管理系统,自动构建系统,自动化测试系统,自动部署系统。

构建一个持续集成环境成本非常低,通过一些开源的工具就能实现。比如,我们使用的SVN + CruiseControl.NET +  NAnt(MSBuild) + xUnit。

使用持续集成,我们需要注意什么?

第一,重视持续集成的结果。

持续集成的结果有两种,不通过(红灯)和通过(绿灯)。尤其是亮红灯时,一定要让团队的所有人都看到,并且相关的人员必须重视,立即停下手头的工作去修复它。我见过有的团队使用一个大显示器,让在团队成员的中间,显示器中显眼的红灯很容易就被团队的成员看见,并且每个人看着都会不爽,直到去修复它。甚至,有的团队使用邮件进行骚扰,当编译不过时,不断的给Breaker或团队所有成员发邮件,直到解决为止。据说ThoughtWorks公司使用一种类似灯笼的东西,集成不过时,灯笼两红灯,非常的生动有趣。

另外一个简单的办法,就是要求团队成员在自己电脑开机时自动启动CCTray(如果使用CCNET的话),团队所有成员通过CCTray及时的得到集成的结果。

“谁破坏了构建,谁就要受到惩罚”,不过这里的“惩罚”并不是真正的惩罚,而是诸如请别人喝可乐之类的。每个人都有犯错误的时候,都有入库时忘记入某些文件的时候,我还记得有个同事因为破坏了构建,导致我和另外一个同事无法工作,最后解决后给我们送上的可乐。

第二,入库前,先在本机集成。

这是一个好习惯。要让团队所有人都养成这个习惯,就必须让本机的集成做的越简单,比如做成一个Bat文件。Martin Fowler的文章里提到在本机集成两次,第一次在代码完成时集成,第二次更新最新的代码下来,如果有冲突,解决冲突后在集成一次。然后再入库。

本机集成通过,并不一定提交后在集成服务器就能通过。通常让构建亮红灯,都是因为本机编译没问题,到了构建服务器就出问题。最常见的原因就是漏了入库文件,以及,本机未更新最新代码进行的集成。

第三,鼓励频繁的集成。

构建一般分为,日构建,实时构建,手工构建。我觉得,日构建肯定是必须的,能做实时构建就做实时构建。在完成一个小的迭代,或是功能时,就加入到构建中,让团队中的其他成员能够获得更加及时可用的代码。频繁的入库,集成,同时也能减少代码冲突产生的代价。

我见过有的团队,采用日构建加手工构建的方式,在进行手工构建时,有时还需要加入一些手工的干预,比如修改某个配置文件,替换某个文件等等。其实这是不鼓励的。应该尽量保证构建的自动执行。

第四,加快集成的速度。

相信任何一个稍微大点的项目都会遇到这样的困境,完整的构建整个项目需要花费几个小时甚至更长的时间。这是难以忍受的,除非在半夜里进行的日构建。如果代码提交后,需要等待1小时才有结果,也是难以忍受的。我们之前就遇到过这样的问题。之后我找了很多办法,将实时构建的时间降了下来。比如将不同的工程区分开来、白天只编译Release,晚上Release和Debug一起编译、通过编写MSbuild插件实现入库文件的智能判断,只编译产生影响的代码工程。之前我写过一篇文章专门介绍过这个方法(CCNET+MSBuild+SVN 实时构建的优化总结)。

第五,自动测试。

CCNET中,有良好的扩展机制,可以在代码编译完成后自动执行单元测试案例。同时,CCNET还支持一些代码风格检查工具以及代码覆盖率工具(如NCover)。除此之外,一些集成测试案例也需要在构建完成后能够自动触发,这些案例通常会依赖一些具体环境,比如外部数据库,案例执行的时间会稍长。为了不影响自动构建的时间,需要使用单独的机器来触发和执行这些案例,甚至做成一个自动化分布式案例执行平台。比如我们自己实现的Box自动化测试平台。

 

三言两语并非以偏概全,而是说说我心里所想的。想要了解更多关于持续集成,还是仔细看看Martin Fowler的持续集成》第二版的中译本。如果有CCNET使用的一些问题,可以来问我。

[温馨提示]:该文章由原博客园导入而来,如排版效果不佳,请移步:http://www.cnblogs.com/coderzh/archive/2010/04/21/talk-about-agile-continuousIntegration.html

微信扫一扫交流

作者:CoderZh
微信关注:hacker-thinking (一个程序员的思考)
本文出处:https://blog.coderzh.com/2010/04/21/talk-about-agile-continuousIntegration/
文章版权归本人所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。