\

看新闻很累？看技术新闻更累？试试，每天上下班路上听新闻，有趣还有料！

\

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

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

\

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

\

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

\

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

\

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

\

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

\

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

\

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

\

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

\

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

\

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

\

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

\

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

最近，Humble与人合著了一书。该书挑战了经验主义，整理并量化分析了公司践行持续交付的效果。在关于Farley的博文的推特主题中，Humble：

\

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

\

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

\

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

\

查看英文原文：