持续集成(Continuous Integration)一直被认为是敏捷开发的重要实践之一,但也有专业人士开始挑战这种观点。Yegor Bugayenko 是 teamed.io 的联合创始人和 CTO,他在最近的一篇博客中毫不客气地指出:“持续集成已死”。
持续集成的目的简单而明确。当有人向代码库的主分支提交代码的时候,后台的持续集成服务器会尝试去构建整个产品,包括编译、单元测试、集成测试、质量分析等等。结果只有两种:成功或失败。如果结果失败了,那就说明有人提交了对产品有害的代码。
单从技术上讲确实如此,但 Bugayenko 认为,从整个组织的角度来讲,这却是不合时宜的。他认为最大的问题在于:
如果构建失败,整个开发团队必须停下手里的工作,立刻修复他们的错误。
谁愿意停下来呢?产品经理盯着产品早日上市,而项目经理,需要为项目的最后期限负责,被压力赶着走的程序员更不会了。Bugayenko 描述了他所见到的真实情况:
我们开始忽略持续集成的状态,不管是成功还是失败。我们还是埋头干我们手里的事情。也许明天,也许周一,等我们有空的时候再修复构建的错误。
Bugayenko 也尝试了用严格的纪律来保证团队及时修复错误,但这样也有问题:
如果这样做,你的最终结局就是得到一种“由恐惧驱动的开发模式”。程序员会害怕提交代码到仓库中,因为他们知道如果导致构建错误,他们至少要道歉。
严格的纪律只会使情况更糟糕,程序员更愿意把代码保留在本地以免犯错,从而拖慢了开发流程。等到必须要提交的时候,一次提交很多代码,如果出错,又很难回溯。
对于这种困境,Bugayenko 给出了他认为可行的方案:“对主分支实行只读策略”。这种方式禁止开发人员直接向主分支提交任何代码,取而代之的是一个脚本,它会在合并代码前做一系列测试,确保无错才允许提交。这样做解决了前面的两个问题:主分支永远是“干净”的;程序员也不用再担心犯错,因为他们最多就是被脚本拒绝提交而已。
Bugayenko 还给出了多篇相关文章来支持自己的观点。在博客的评论区,也有读者指出,Bugayenko 所说的解决方案在现实中一直被一些代码审核系统所采用。
感谢郭蕾对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。
评论 1 条评论