[翻译]whatistrunkbaseddevelopment

2019独角兽企业重金招聘Python工程师标准>>>

原文地址 https://paulhammant.com/2013/04/05/what-is-trunk-based-development

什么是基于主干开发&＃xff08;简称TBD&＃xff09;&＃xff1f;

什么是TBD&＃xff1f;

它是一个软件开发的分支模型。历史上&＃xff0c;它也被称为“主线/mainline”(见下文)。它需要更多的专注和严格&＃xff0c;而不是(在共享的源代码控制服务器上)建立一个分支来满足一时的需要。虽然您可以在不进行持续集成(CI)的情况下完成&＃xff0c;就像许多开源项目所做的那样&＃xff0c;但是对于企业开发来说&＃xff0c;您必须将CI连接到主干&＃xff0c;强制执行“提交是好的”的多个方面。在本文中&＃xff0c;我没有提到开发人员在他们自己的工作站上如何通过“本地”分支来适应他们的逐小时活动。这都是关于共享仓库的&＃xff0c;在这里&＃xff0c;多个开发人员集成/合并他们的日常工作以达到更好的效果:&＃xff09;

基于主干开发(TBD)是所有开发人员(针对特定的可部署单元)在源代码控制下提交到一个共享分支的地方。这个分支通常被称为主干&＃xff0c;甚至可能被命名为“主干/trunk”。开发人员可以在他们自己的开发工作站中进行一些多分支开发(比如使用Git)&＃xff0c;但是当他们通过更改或bug修复“完成”时&＃xff0c;应该返回到共享主干。如果它不在那里&＃xff0c;那就不算“完成”——注意那个小谎言。请参阅下面关于pull-requests的部分。开发人员不允许在共享位置创建发布分支。只有发布工程师才会致力于这些发布分支&＃xff0c;并真正创建每个发布分支。如果有意愿&＃xff0c;他们也可以挑选个人向该分支作出承诺。在一个版本被另一个版本取代之后&＃xff0c;发布分支很可能被删除。主干作为一个模型&＃xff0c;已经使用了大约20年。最初是由开源社区推动的&＃xff0c;但在“企业级”中&＃xff0c;当ClearCase(和其他人)发布其他分支模型成为主流时&＃xff0c;情况就不那么乐观了。谷歌和Facebook&＃xff0c;今天&＃xff0c;实践TBD风格的分支模型。如果不完全正确&＃xff0c;那就足够接近。无论是谷歌还是Facebook都公开了他们TBD的使用情况&＃xff0c;它的市场份额都在不断增长。

但是这里有分支!

是的&＃xff0c;有这种情况。但是关于发布。“发布分支”是策略。发布分支在被另一个发布分支取代之前会存在很短的时间&＃xff0c;它在创建时从主干中获取所有内容。就合并而言&＃xff0c;只支持从主干到发布分支的遴选cherry-pick。对于许多企业&＃xff0c;只会合并错误修复。对于Facebook(他们每周从发行分支上进行10次直播)来说&＃xff0c;如果利益相关者优先考虑的话&＃xff0c;增强功能的合并也会发生。

几乎所有人都同意&＃xff0c;bug是固定在主干上并合并到发布分支上的&＃xff0c;而不是固定在发布分支上并合并到主干上的。通常只有很少一部分人可以提交到发布分支。

Pull-Requests 还是分支!

好的&＃xff0c;所以GitHub率先将pull-request作为开发工作流。这与TBD相当兼容&＃xff0c;因为一个特性/任务是在不在主干/主服务器上的位置进行编组的&＃xff0c;但可以快速完成。通常情况下&＃xff0c;代码审查发生在那里&＃xff0c;CI会自动权衡PR分支是否有资格合并到主干/主分支。如果一切正常&＃xff0c;PR被合并到主/主干中&＃xff0c;然后删除&＃xff0c;留下一个平滑的主干/主时间轴。当然&＃xff0c;稍后作为pull-request主题的特性/任务分支应该是一个人或一对分支&＃xff0c;并且寿命很短(比如一天)。也有一些变体——“fork”和原始的简单分支都是很好的pull-request选择。只有代码仓库读写权限指南应该使用。

开发的义务

开发人员不会用任何提交破坏构建。这需要很多规则&＃xff0c;也许这也是为什么谷歌和Facebook的诱导程序对于开发者来说是冗长的。回滚/恢复提交是一种防止由此造成损害(损失时间)的策略。更复杂的公司将使用预提交验证。开发人员养成了这样的习惯:通过同步主干的最新版本&＃xff0c;从根本上/从头构建&＃xff0c;再次检查它们的功能变化&＃xff0c;然后提交&＃xff0c;来证明提交是好的。在早期&＃xff0c;包括在ThoughtWorks中&＃xff0c;开发人员有一个“标记”来证明他们并没有破坏构建——在他们进行验证的过程中&＃xff0c;没有人能够控制鸡。橡胶鸡已经被使用了十多年&＃xff0c;但是任何东西都可以(感谢Jez的链接)。

持续集成CI

像Jenkins这样的持续集成会参与到这个提交中&＃xff0c;并通过构建管道构建、测试、部署、测试等等。它可能会检测到故障&＃xff0c;这很可能是因为开发人员没有证明他们的提交或执行令牌操作。另一个问题可能是开发人员在提交之前没有添加新的源文件。这很容易/很快就可以补救&＃xff0c;而且“前滚”也可以。

需要“太长时间”才能完成的更改

开发人员使用一种称为分支抽象(BbA)的技术来确保他们能够在更长的时间内完成更复杂的更改。我已经写过很多次了。Martin Fowler强调了这一点&＃xff0c;Jez Humble也写过同样的文章。它减轻的风险是分支机构的增加&＃xff0c;以及那些“临时”分支机构没有按照人们希望的时间表完成工作。

My own case studies

From 2005, a move from crazy branching towards TBD (a US FX trading bank).

主干开发回顾

Quick reminder of what TBD is: ● 开发提交到一个单独的主干 ● 发布工程师 (or 编译员工) 创建分支, 并且多多少少遴选到分支 ○ 只有一个缺陷不能在树干修复, 才许可给在发布分支修复,并择遴选回主干。如果你用到了发布分支的概念&＃xff0c;那就值得记住: ● 主干开发意味着普通的开发人员承诺不提交到发布分支. ● 主干开发意味着你要删除旧的发布分支,而不是合并回主干

什么绝对不是TBD

开发者提交到多个分支

包含相同源文件的分支。参考BbA上面-你应该这样做。高级开发人员通常会声称他们有一个特殊的案例&＃xff0c;并且希望在一个分支上完成。问题在于共享源控制服务器上的分支的增加&＃xff0c;它们的“临时”生命期的长度&＃xff0c;以及当有许多开发人员和许多提交到某个地方时合并的困难。 Branches containing the same source files, that is. Refer BbA above - you should be doing it. Often senior devs would claim they have a special case, and want to do it on a branch. The pitfall is the proliferation of branches on the shared source-control server, the length of their ‘temporary’ life, and the difficulty of merging when there are lots of developers and lots of commits to one place or another. 即使是喜欢树干概念的人也会反复讨论这一方面的问题。我将在沙子上画一条线&＃xff0c;并且说你不应该为特性(在那个共享仓库上)创建分支&＃xff0c;不管它们需要多长时间&＃xff0c;不管它们是否超过了发布日期。你应该做BbA。

不在单一分支开启一个持续集成管道

当然&＃xff0c;作为个人实践&＃xff0c;您可以防止破坏&＃xff0c;许多开源团队会认为没有CI是好的。但对于拥有数十名开发人员的企业土地&＃xff0c;您需要彻底的CI。

手动维护依赖版本号

可以用版本化的方式表示可构建组件的依赖关系。例如&＃xff0c;Log4J目前是1.2.17&＃xff0c;由Apache维护。你不会把他们的资源拉进你的资源控制。您将依赖于一个二进制文件&＃xff0c;并为您自己的构建文件烘焙版本号(在源代码控制下)。对于您自己的东西&＃xff0c;它可能是在CI的不同阶段构建的&＃xff0c;您不应该为特定的构建指定版本号。借鉴Maven的习惯用法&＃xff0c;您应该依赖于CI下的移动目标。说“OurCommonThings-1.1-SNAPSHOT”&＃xff0c;但要确保你是在“正确”的CI构建阶段构建的。您不打算这样做&＃xff0c;但是如果您不使用编译并使用最新版本的everything进行测试&＃xff0c;您就不能持续地进行集成。

CI管道中更核心的实现将使用我上面建议的有争议的“1.1-SNAPSHOT”之外的其他东西。It(以及Maven本身)在企业开发中是一个有争议的问题。对于颠覆或强制安装&＃xff0c;存储库修订号可以是您使用的——“1.1-12345”。或者&＃xff0c;构建号可能很流行(所有CI工具都可以为它们执行的脚本提供一个构建号)。

不在root下持续集成

在常规配置中&＃xff0c;CI应该从头构建所有内容&＃xff0c;而不是依赖于之前构建的任何内容。一些更复杂的CI基础设施(比如ThoughtWorks Studios的Go)拥有一种更可证明的/指纹的方式&＃xff0c;可以使用预构建块进行战术上的操作&＃xff0c;但常规安装应该从零开始(尽可能快地)。

基于主干开发是“一切最新版本”的另一个变体。

连续版本的并发开发

有些企业同时处理一系列发行版。他们打算使用运行时切换来进行暗部署&＃xff0c;但也可能在生成的二进制文件中使用构建时切换到子集功能&＃xff0c;这取决于他们想在CI阶段测试什么。它们可能有多个CI管道用于同一主干&＃xff0c;这证明“amazon_one_click&＃61;true”和“amazon_one_click&＃61;false”交替构建并通过测试。这两个失败中的任何一个仍然是提交失败&＃xff0c;并且可能发生回滚/恢复。

您只需要为您希望实时发布的版本设置不同排列的切换管道。如果“管理”取消了一个版本的特性(由一个开关激活)&＃xff0c;或者重新排列版本&＃xff0c;那么您可以尽快重新配置CI管道。CI很快就澄清了“重新规划”的成本和时间影响&＃xff0c;以及由此导致的每个主干的传递/失败视图。你永远不会去测试不合理的切换排列。

顺便说一句&＃xff0c;极限编程社区正确地指出&＃xff0c;连续发行版的连续开发更可取。