BT

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

更多的特性分支意味着更少的持续集成

| 作者 Ben Linders 关注 27 他的粉丝 ,译者 杜小芳 关注 2 他的粉丝 发布于 2015年10月28日. 估计阅读时间: 7 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

很多团队现在都默默地放弃了持续集成,原因是进行特性分支更容易,基于主干的开发欠升值,Steve Smith说。在Agile Tour London 2015上,他将讨论持续集成的死亡。

InfoQ采访了Steve Smith,关于不同分支的方法,以及他们如何与持续集成相结合,还有为什么构建功能分支会妨碍持续集成和持续交付。

InfoQ:您能简要介绍一些正在使用的不同的分支方法吗?

Steve Smith:当然。在过去的一年里,我已经写了一系列文章,关于一些不同的版本控制策略,所有的我已经在我的职业生涯中使用过。我想评估历史背景建立不同风格分支的一种分类方法,评估其与持续集成的兼容性 - 并回答一个同事的问题:“我构造功能分支如此成功,为什么还要基于主干进行开发?“

在20世纪90年代,长生命周期的发布功能分支(Release Feature Branching)以及如ClearCase,Perforce和MKS工具很普遍。开发者在共享功能分支上进行几个星期,几个月,甚至可能数年的开发,并在发布产品前测试分支。之后会有一个痛苦的,耗时的合并到主干以及回归测试的过程。我曾在一个公司里使用MKS做过两年的发布功能分支开发,我不建议这样做。

从21世纪初开始基于干线的开发已开始使用诸如Subversion和Perforce的工具。开发者在主干上工作,每天少量增量多次提交。在主干上进行测试,用主干或者短期存在的分支进行发布。并行功能开发在使用如Feature TogglesBranch By Abstraction的工具下完成,支持用户首选项,运行时配置。在基于主干开发上,我在三个不同公司里工作了7年,使用Subversion,Mercurial,和Git,我强烈地给所有人推荐- 同事,家人,朋友,甚至大街上的陌生人。

在2000年代中期分布式版本控制系统(DVCS)成为主流,而基于主干开发也同样适用于VCS和DVCS。在DVCS里创建分支成本更低,导致出现更加轻便功能分支策略。一个变种叫集成功能分支,跟如Git和Mercurial这些工具一起使用。开发人员在私人分支上进行一天的开发, 然后合并到一个长生命周期的集成分支进行测试,之后集成分支将并入主干,或在并主干前并入Git Flow功能发布分支。我使用Git Flow做了6个月集成功能分支开发,并不推荐它。

最后,由于2000年代后期编译功能分支横空出世,由于Git,Mercurial,特别是GitHub Flow。开发者在个人功能分支进行一天的工作之后合并到主干,用于测试和产品发布。我使用GitHub Flow在编译功能分支上进行了为期一年的开发,我推荐它 - 尽管很谨慎。

InfoQ:你能否详细说明这些不同的分支方法将如何与持续集成相结合?

Steve Smith:首先,持续集成不是一个工具 - 它是一种实践,团队的每一个成员提交到主干,一天至少一次,可由编译服务器如Jenkins或TeamCity验证。因此,我们可以评估一个版本控制策略,基于它能够方便进行日常提交,到主干中(叫Master也可以)。首先,发布功能分支和集成功能分支都与持续集成明显不兼容,因为前者在共享分支上经历了数月的开发,后者在之前的主干上包含过多的分支。

基于主干开发是持续集成的代名词,并有很好的理由 - 当每一个团队成员每天数次提交到主干,持续集成就实现了。也有其他优点,如推动团队成员分解代码库,成为一个较小的,模块化的演化架构,功能切换为使用Canary ReleaseDark Launching

编译功能分支是非常有趣的。表面看,私人功能分支审查后合并到主干,似乎与持续集成兼容,但左思右想,我得出的结论是编译功能分支可能与持续集成不兼容 - 由于开发者更多的修改,功能分支最终会被超过一天,由于开发商的工作量审查需要一天以上,而因为开发人员以异步方式进行主干合并和编译,编译变得更慢更破碎。

InfoQ:你会在Agile Tour London上谈“持续集成之死”,为什么?

Steve Smith:在2014年的#IsTDDDead辩论,我环顾我的团队,看到大家都在利用GitHub Flow练习测试驱动开发,“测试驱动开发生命力旺盛,但持续集成是真正的麻烦”。

编译功能分支现在惊人流行,我猜想是由于a)Git和GitHub是好工具和b)企业为了创意和灵感越来越多地转向了开源社区。在Stack Overflow 2015 survey上指出,16694名开发者中有11519人(69%)在使用Git作为他们的源代码管理工具。2015年七月的Git Press报告说有1000万用户和2600万个版本库。现在,Git是一个非常好的工具,GitHub同样也是。但是,持续集成是惊人重要- 这是持续交付的基础 - 我相信很多团队将很难实现长期的,可持续的持续交付程序,如果他们盲目地采用编译功能分支的话。

InfoQ:您能分享一些资源让InfoQ的读者可以用它来了解更多关于分支和持续集成吗?

Steve Smith:关于持续集成的信息,我建议Martin Fowler的持续集成的原创文章和James Shore和Shane Warden的敏捷开发的艺术。有关分支模型和源代码管理,Paul Hammant的博客是信息的重要来源。

InfoQ将覆盖Agile Tour London 2015的新闻,Q&As和文章:

第三届Agile Tour London将2015年10月23日星期五举行,将为所有对敏捷开发感兴趣的人开放:从敏捷新手到敏捷实践者。

查看英文原文:More Feature Branching Means Less Continuous Integration


感谢张龙对本文的审校。

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

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

更多的特性分支意味着更多的持续集成 by Zhang William

每个 feature branch 都可以运行 CI

允许的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通知我

1 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT