以主干开发作为持续交付的基础

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

早在他们的重要著作《持续交付》一书于2011 年发布之前， Dave Farley 和 Jez Humble 就一直在宣传主干开发的重要性。近日，Farley 在发文探讨了主干开发以及他在三月份的 PIPELINE 大会上做完有关“优化持续交付”的演讲之后所遇到的强烈反对。作为对这件事的回应，Humble 在一个冗长的Twitter 主题中分享了他的观点，从文化角度探讨了主干开发，从而理解它和程序员心理的关系。

Farley 将主干开发描述成他可以“获得最多推送”的实践。主干开发鼓励团队采用这样一种方式，他们向一个共享的、总是处于可发布状态的主干增量推送变化，至少每天一次。与使用生命周期更长的特性分支相比，这有助于所有人都能够了解和分享与正在构建的产品有利害关系的反馈。Farley 写道，“在他们正在开发的‘特性’完成之前，大部分团队都不会合并他们的分支”，他将主干开发视为持续集成（CI）和持续交付（CD）的基础。他写道，这样的反馈隔离是违反 CI 的：

……如果 CI 是要尽可能经常地暴露变化，那么我们就可以获得有关我们的想法的很棒的反馈，而分支，不管哪种形式的分支，都是要隔离变化。按照设计，分支是要把变化隐藏在一部分代码中，让其他开发人员看不到。这是有悖于 CI 的，答案就在其名字“持续集成”中。

Farley 指出，在一个动态变化的代码库中，特性分支往往会误导人们对稳定性的认识：

从个体开发者的角度来说，特性分支非常好，但是从团队的角度来说，则是次优的。我们都希望能够忽视其他人在做什么，并继续自己的工作。遗憾的是，代码不那样。即使是结构很好的代码库，有漂亮的关注点分离，有巧妙松耦合的组件，有些变化也会影响到系统的其他部分。

接着，Humble 写道，主干开发是“把团队需求置于个体需求之上。”他指出，高效的主干开发鼓励沟通和小批量开发：

我们使用版本控制把我们正在做的工作传达给团队的其他人。要想足够经常地这样做，我们就得非常小批量的开发。这与许多开发人员喜欢的工作方式背道而驰：在再次合并之前，自己坐在哪里，顺着一个编程兔子洞一直走下去。

Humble 写道，CI 及主干开发的先决条件是“社会化和团队”活动，“挑战开发英雄的神话”：

因此，我猜测，特性分支和 CI/ 主干开发的比较之所以成为一个敏感问题，是因为：我们在打破何谓“好”程序员的其中一个核心信念。也是因为人们接受的训练不是小批量开发，他们觉得这样不习惯。

谈到团队应该针对测试以及与将要发布的东西不匹配的分支做些什么工作时，Farley 写道：

有一点确信无疑，就是测试发生在向主干合并的时候。只有在这个时候，你才能诚实地说，“是的，我的修改没有和任何人的冲突。”在此之前，你会希望其他人没有在另外的分支上做妨碍你合并的事情。

Farley 写道，主干开发是成功实现 CI/CD 的核心内容之一：

CI 并不是一个简单的方法；它经过周密的考虑，而且在世界上部分最成功的企业里有着非常广泛的应用。主干开发是 CI/CD 的核心实践，在没有主干开发的情况下，真得很难获得 CI 或 CD 的所有好处。

Farley 反驳了人们对于主干开发的反对意见，他列举了“ DevOps 现状报告”以及他的个人经验，几十年来，他在不同的团队规模、编程语言和范围内都有着成功的实践。

最近，Humble 与人合著了 _ The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations _ 一书。该书挑战了经验主义，整理并量化分析了公司践行持续交付的效果。在关于 Farley 的博文的推特主题中，Humble写道：

……在“DevOps 现状报告”中，我们对主干清理做了些研究，这也出现在了我们的新书 _Accelerate_ 中。结论显而易见。那些对主干或者存在时间不超过的一天的分支进行清理的团队显然更高效。

在 _Accelerate_ 一书的前言中，Martin Fowler 总结了使用这些做法的好处：

他们描述了高效的 IT 交付组织如何用一个小时的时间获取提交到主干的代码并让它在生产环境中运行起来，很少有组织要花几个月来完成这个过程。他们这样每天多次升级软件，而不是几个月一次，这提升了他们使用软件开拓市场、响应事件以及比竞争对手更快地发布特性的能力。这极大地提高了响应性，但又不以牺牲稳定性为代价，这些组织发现，他们因为升级而导致故障的情况只是那些不那么高效的组织的一小部分，而且通常在一个小时内就可以修复。

查看英文原文： Trunk Based Development as a Cornerstone for Continuous Delivery