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