转载

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

很多团队现在都默默地放弃了持续集成，原因是进行特性分支更容易，基于主干的开发欠升值，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 Toggles 和 Branch 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 Release 和 Dark 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同样也是。但是，持续集成是惊人重要- 这是持续交付的基础 - 我相信很多团队将很难实现长期的，可持续的持续交付程序，如果他们盲目地采用编译功能分支的话。