BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 曹知渊 关注 1 他的粉丝 发布于 2014年10月18日. 估计阅读时间: 3 分钟 | ArchSummit北京2018 共同探讨机器学习、信息安全、微服务治理的关键点

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

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

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

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

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

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

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

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

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

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

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


感谢郭蕾对本文的审校。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

不就是facebook早就实施的两阶段提交吗 by see sai

自己提交的代码或代码审查有问题却怪CI,不过大陆的公司也有很多应该是这样,特别是在良莠不齐的小公司里。

标题党啊 by 郭 雪品

标题党,懂得少而结论下得多。

关键还是集成的把握点 by 喻 博

及时提交自己的模块,有问题测试通不过,继续修改。又没有放到发版上去,这个持续集成的应该也有时间点和任务的一个通过的界定吧

标题党 by 唐 鹏

没什么营的养文章

必须赞一个 by guo xiaodong

老外的曲线救国方式真的不错,现在这种以人为驱动的开发模式越来越被重视,看来这种重点以质量文化建设为主,把人的主管能动性带动质量和效率的提升的管理思路发挥的越来越好。

就知道喷 by Li Seijin

国内的程序员就是这,就知道喷,其实文章的观点里还是有些值得我们学习的地方的。

文章怎么看都可以有用 by 李 兆欣

这背后其实隐藏了如何避免工具和方法对公司文化造成直接冲突的课题。很多公司不能推广先进方法,就是被挡在文化上,那怎么办?人家文章提出的是投石问路举一反三的问题。心中有屎,看到的都是屎。

持续集成本来就需要起码的脚本通过后才能合并代码 by 杨 世玲

自己使用的方式有问题, 怎么能怪持续集成捏?


字写不好, 埋怨笔.

Re: 持续集成本来就需要起码的脚本通过后才能合并代码 by 杨 世玲

不过持续集成的工具还有很大提升的空间.

作者应该看看Google的软件测试之道 by Yu Daniel

看他们是怎么解决问题的

“持续集成”全体躺枪,却也是个无奈的现实 by Zhefu Zhou

这个鬼佬的本意应该是“简单粗暴的持续集成不应该继续下去了”。事实上,如果没有准备好代码审查机制,严格的测试驱动开发流程,持续集成就是一个惹祸精,非常善于制造团队内部矛盾。实际上持续集成的改革是不应该独立进行的,所有配套的机制和流程都要尽早跟上,否则带来的只是信心的流失。就好像当年洋务派那种“头痛医头脚痛医脚”的不彻底运动,只会让中国在甲午年跌得更惨。

Re: “持续集成”全体躺枪,却也是个无奈的现实 by while true

终于看到个客观的答复了。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

12 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT