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