[关闭]
@tinadu 2015-10-20T17:51:06.000000Z 字数 2271 阅读 1633

更多功能分支意味着更少的持续集成

未分类


很多团队现在都默默地放弃了持续集成,原因是进行功能分支更容易,基于主干的开发欠升值,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日星期五举行,将为所有对敏捷开发感兴趣的人开放:从敏捷新手到敏捷实践者。

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注