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

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

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

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

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

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

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

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

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

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

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

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

感谢郭蕾对本文的审校。

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