2019独角兽企业重金招聘Python工程师标准>>>
什么是基于主干开发(简称TBD)?原文地址 https://paulhammant.com/2013/04/05/what-is-trunk-based-development
什么是TBD?
它是一个软件开发的分支模型。历史上,它也被称为“主线/mainline”(见下文)。 它需要更多的专注和严格,而不是(在共享的源代码控制服务器上)建立一个分支来满足一时的需要。虽然您可以在不进行持续集成(CI)的情况下完成,就像许多开源项目所做的那样,但是对于企业开发来说,您必须将CI连接到主干,强制执行“提交是好的”的多个方面。 在本文中,我没有提到开发人员在他们自己的工作站上如何通过“本地”分支来适应他们的逐小时活动。这都是关于共享仓库的,在这里,多个开发人员集成/合并他们的日常工作以达到更好的效果:)
基于主干开发(TBD)是所有开发人员(针对特定的可部署单元)在源代码控制下提交到一个共享分支的地方。这个分支通常被称为主干,甚至可能被命名为“主干/trunk”。开发人员可以在他们自己的开发工作站中进行一些多分支开发(比如使用Git),但是当他们通过更改或bug修复“完成”时,应该返回到共享主干。如果它不在那里,那就不算“完成”——注意那个小谎言。请参阅下面关于pull-requests的部分。 开发人员不允许在共享位置创建发布分支。只有发布工程师才会致力于这些发布分支,并真正创建每个发布分支。如果有意愿,他们也可以挑选个人向该分支作出承诺。在一个版本被另一个版本取代之后,发布分支很可能被删除。 主干作为一个模型,已经使用了大约20年。最初是由开源社区推动的,但在“企业级”中,当ClearCase(和其他人)发布其他分支模型成为主流时,情况就不那么乐观了。谷歌和Facebook,今天,实践TBD风格的分支模型。如果不完全正确,那就足够接近。无论是谷歌还是Facebook都公开了他们TBD的使用情况,它的市场份额都在不断增长。
但是这里有分支!
是的,有这种情况。但是关于发布。“发布分支”是策略。发布分支在被另一个发布分支取代之前会存在很短的时间,它在创建时从主干中获取所有内容。就合并而言,只支持从主干到发布分支的遴选cherry-pick。对于许多企业,只会合并错误修复。对于Facebook(他们每周从发行分支上进行10次直播)来说,如果利益相关者优先考虑的话,增强功能的合并也会发生。
几乎所有人都同意,bug是固定在主干上并合并到发布分支上的,而不是固定在发布分支上并合并到主干上的。通常只有很少一部分人可以提交到发布分支。
Pull-Requests 还是分支!
好的,所以GitHub率先将pull-request作为开发工作流。这与TBD相当兼容,因为一个特性/任务是在不在主干/主服务器上的位置进行编组的,但可以快速完成。通常情况下,代码审查发生在那里,CI会自动权衡PR分支是否有资格合并到主干/主分支。如果一切正常,PR被合并到主/主干中,然后删除,留下一个平滑的主干/主时间轴。当然,稍后作为pull-request主题的特性/任务分支应该是一个人或一对分支,并且寿命很短(比如一天)。也有一些变体——“fork”和原始的简单分支都是很好的pull-request选择。只有代码仓库读写权限指南应该使用。
开发的义务
开发人员不会用任何提交破坏构建。这需要很多规则,也许这也是为什么谷歌和Facebook的诱导程序对于开发者来说是冗长的。回滚/恢复提交是一种防止由此造成损害(损失时间)的策略。更复杂的公司将使用预提交验证。开发人员养成了这样的习惯:通过同步主干的最新版本,从根本上/从头构建,再次检查它们的功能变化,然后提交,来证明提交是好的。在早期,包括在ThoughtWorks中,开发人员有一个“标记”来证明他们并没有破坏构建——在他们进行验证的过程中,没有人能够控制鸡。橡胶鸡已经被使用了十多年,但是任何东西都可以(感谢Jez的链接)。
持续集成CI
像Jenkins这样的持续集成会参与到这个提交中,并通过构建管道构建、测试、部署、测试等等。它可能会检测到故障,这很可能是因为开发人员没有证明他们的提交或执行令牌操作。另一个问题可能是开发人员在提交之前没有添加新的源文件。这很容易/很快就可以补救,而且“前滚”也可以。
需要“太长时间”才能完成的更改
开发人员使用一种称为分支抽象(BbA)的技术来确保他们能够在更长的时间内完成更复杂的更改。我已经写过很多次了。Martin Fowler强调了这一点,Jez Humble也写过同样的文章。它减轻的风险是分支机构的增加,以及那些“临时”分支机构没有按照人们希望的时间表完成工作。
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 编译员工) 创建分支, 并且多多少少遴选到分支 ○ 只有一个缺陷不能在树干修复, 才许可给在发布分支修复,并择遴选回主干。 如果你用到了发布分支的概念,那就值得记住: ● 主干开发意味着普通的开发人员承诺不提交到发布分支. ● 主干开发意味着你要删除旧的发布分支,而不是合并回主干
什么绝对不是TBD
开发者提交到多个分支
包含相同源文件的分支。参考BbA上面-你应该这样做。高级开发人员通常会声称他们有一个特殊的案例,并且希望在一个分支上完成。问题在于共享源控制服务器上的分支的增加,它们的“临时”生命期的长度,以及当有许多开发人员和许多提交到某个地方时合并的困难。 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. 即使是喜欢树干概念的人也会反复讨论这一方面的问题。我将在沙子上画一条线,并且说你不应该为特性(在那个共享仓库上)创建分支,不管它们需要多长时间,不管它们是否超过了发布日期。你应该做BbA。
不在单一分支开启一个持续集成管道
当然,作为个人实践,您可以防止破坏,许多开源团队会认为没有CI是好的。但对于拥有数十名开发人员的企业土地,您需要彻底的CI。
手动维护依赖版本号
可以用版本化的方式表示可构建组件的依赖关系。 例如,Log4J目前是1.2.17,由Apache维护。你不会把他们的资源拉进你的资源控制。您将依赖于一个二进制文件,并为您自己的构建文件烘焙版本号(在源代码控制下)。 对于您自己的东西,它可能是在CI的不同阶段构建的,您不应该为特定的构建指定版本号。借鉴Maven的习惯用法,您应该依赖于CI下的移动目标。说“OurCommonThings-1.1-SNAPSHOT”,但要确保你是在“正确”的CI构建阶段构建的。您不打算这样做,但是如果您不使用编译并使用最新版本的everything进行测试,您就不能持续地进行集成。
CI管道中更核心的实现将使用我上面建议的有争议的“1.1-SNAPSHOT”之外的其他东西。It(以及Maven本身)在企业开发中是一个有争议的问题。对于颠覆或强制安装,存储库修订号可以是您使用的——“1.1-12345”。或者,构建号可能很流行(所有CI工具都可以为它们执行的脚本提供一个构建号)。
不在root下持续集成
在常规配置中,CI应该从头构建所有内容,而不是依赖于之前构建的任何内容。一些更复杂的CI基础设施(比如ThoughtWorks Studios的Go)拥有一种更可证明的/指纹的方式,可以使用预构建块进行战术上的操作,但常规安装应该从零开始(尽可能快地)。
基于主干开发是“一切最新版本”的另一个变体。
连续版本的并发开发
有些企业同时处理一系列发行版。他们打算使用运行时切换来进行暗部署,但也可能在生成的二进制文件中使用构建时切换到子集功能,这取决于他们想在CI阶段测试什么。它们可能有多个CI管道用于同一主干,这证明“amazon_one_click=true”和“amazon_one_click=false”交替构建并通过测试。这两个失败中的任何一个仍然是提交失败,并且可能发生回滚/恢复。
您只需要为您希望实时发布的版本设置不同排列的切换管道。如果“管理”取消了一个版本的特性(由一个开关激活),或者重新排列版本,那么您可以尽快重新配置CI管道。CI很快就澄清了“重新规划”的成本和时间影响,以及由此导致的每个主干的传递/失败视图。你永远不会去测试不合理的切换排列。
顺便说一句,极限编程社区正确地指出,连续发行版的连续开发更可取。
名不副实
mianline是另一回事
好的,传统意义上的“mainline”是trunk的同义词,对于基于主干开发的人一直使用“主线”来描述这一点。问题是“mianline”从1993年开始也被ClearCase社区使用,它指的是一种浪费和延迟的分支模式,如下所示:
这也是一个“迟到的”的集成设计,而TBD是“最早”的集成流程,这是开发过程中成本降低的关键概念之一,也是最大的助推器。这个分支模型的另一个事实是,挂起发布分支的分支,这些分支应该是临时的。
所有,总结,mianline对于很多软件开发人员来说意味着别的东西。
功能切换
最近我听说人们把TBD称为“功能切换”。马丁•福勒(Martin Fowler)将这种长期存在的做法命名为该行业。它经常与TBD一起使用,但不是必须的。它可以与任何分支模式一起使用,而且可能与开发软件服务并将其投入使用一样古老。
在之前的一个客户端中,我们也谈到了构建时切换。对于maven来说,这些配置文件是这样的:
# with amazon one click
mvn -p amazon_one_click install# without amazon one click
mvn install
因此,对于该客户端来说,运行时的toggles与构建时的toggles (Maven配置文件)不同,当然有些是两者兼而有之。如前所述,CI管道将启动commit以实现合理的切换排列。
持续发布 (部署)
这是简单的TBD和CI用法的改进。Jez有一本很有名的书,它是必不可少的阅读材料。
感想…
Jez Humble勘误, 有一句很好的引言“分支不是问题,合并才是问题”(这是TBD试图解决的一个问题的一种说法)
更新
June 30th, 2016 - We smile on Pull Requests, of course.