另一种声音:持续集成已死

阅读数:7649 2014 年 10 月 17 日

话题:持续集成语言 & 开发架构

持续集成(Continuous Integration)一直被认为是敏捷开发的重要实践之一,但也有专业人士开始挑战这种观点。Yegor Bugayenko 是teamed.io的联合创始人和 CTO,他在最近的一篇博客中毫不客气地指出:“持续集成已死”。

持续集成的目的简单而明确。当有人向代码库的主分支提交代码的时候,后台的持续集成服务器会尝试去构建整个产品,包括编译、单元测试、集成测试、质量分析等等。结果只有两种:成功或失败。如果结果失败了,那就说明有人提交了对产品有害的代码。

单从技术上讲确实如此,但 Bugayenko 认为,从整个组织的角度来讲,这却是不合时宜的。他认为最大的问题在于:

如果构建失败,整个开发团队必须停下手里的工作,立刻修复他们的错误。

谁愿意停下来呢?产品经理盯着产品早日上市,而项目经理,需要为项目的最后期限负责,被压力赶着走的程序员更不会了。Bugayenko 描述了他所见到的真实情况:

我们开始忽略持续集成的状态,不管是成功还是失败。我们还是埋头干我们手里的事情。也许明天,也许周一,等我们有空的时候再修复构建的错误。

Bugayenko 也尝试了用严格的纪律来保证团队及时修复错误,但这样也有问题:

如果这样做,你的最终结局就是得到一种“由恐惧驱动的开发模式”。程序员会害怕提交代码到仓库中,因为他们知道如果导致构建错误,他们至少要道歉。

严格的纪律只会使情况更糟糕,程序员更愿意把代码保留在本地以免犯错,从而拖慢了开发流程。等到必须要提交的时候,一次提交很多代码,如果出错,又很难回溯。

对于这种困境,Bugayenko 给出了他认为可行的方案:“对主分支实行只读策略”。这种方式禁止开发人员直接向主分支提交任何代码,取而代之的是一个脚本,它会在合并代码前做一系列测试,确保无错才允许提交。这样做解决了前面的两个问题:主分支永远是“干净”的;程序员也不用再担心犯错,因为他们最多就是被脚本拒绝提交而已。

Bugayenko 还给出了多篇相关文章来支持自己的观点。在博客的评论区,也有读者指出,Bugayenko 所说的解决方案在现实中一直被一些代码审核系统所采用。


感谢郭蕾对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。