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

laofo · 2014年10月20日 · 7 次阅读

另一种声音:持续集成已死 作者 曹知渊

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

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

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

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

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

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

转自:http://www.infoq.com/cn/news/2014/10/continuous-integration

@Laruence: 这些个东西和概念本来没错, 但是很多人脱离实际使用场景有目的的鼓吹和推广, 才造就了不少的"无用"的误会.

把 continous build 放在 commit 之前,这样对 trunk/mainline 有害的代码就不可能进去,无需道歉,自己解决完了再提交就好了。

请问如何放在 commit 之前? Jenkins 可以支持吗

Jenkins validated merge plugin,但不是免费的。

需要 登录 后方可回复。