共计 5698 个字符，预计需要花费 15 分钟才能阅读完成。
引言
在阿里外部，风行着许多有意思的工程实际。有些实际通过工具和流程嵌在团体的大环境里，外界不容易复制，有些实际则是表露在大家的日常习惯里，被默默的恪守。比方分支治理这件事，其实属于工具和习惯各占一半，并且颇有阿里特色的成分，适宜作为一个例子。阿里有很多的研发团队，不同事业部应用的公布流程、分支策略并非整齐划一，但总体上看是比拟规整的。其中有一种支流的公布模式以及对应的分支应用形式，称为“AoneFlow”。这套工作模式思路独特，在阿里以外的中央并不多见。本文围绕这些实际，聊一聊分支治理的话题。
作者：林帆（花名金戟），阿里巴巴研发效力事业部技术专家。
细数分支模式
说到分支管理模式，咱们最耳熟能详的莫过于 TrunkBased 和 GitFlow。
TrunkBased 模式是继续集成思维所崇尚的工作形式，它由单个骨干分支和许多公布分支组成，每个公布分支在特定版本的提交点上从骨干创立进去，用来进行上线部署和 Hotfix。在 TrunkBased 模式中，没有显性的个性分支。当然实际上 Git 的分布式特色天生容许每个人有本地分支，TrunkBased 也并非排挤短期的个性分支存在，只不过在说这种模式的时候，大家通常都不会明确强调它罢了。
尽管近年来有许多不错的案例，但 TrunkBased 模式并没有一统天下。它的毛病比拟显著，太多的团队同时工作在骨干上，到公布的时候就可能呈现劫难（尤其是多版本并行开发的状况）。补救的措施是 FeatureToggle 以及频繁的集成和足够的测试笼罩，这对开发团队的能力提出了比拟高的要求。目前 TrunkBased 模式次要用在不须要同时保护多个历史版本的 SaaS 型我的项目，特地是通过微服务革新的各种小型服务上。
TrunkBased 模式有两种常见演进版本。OneFlow 模式参考了 TrunkBased 的许多思维，对操作流程做了更严格的定义，减少了 Hotfix 分支等内容。多骨干模式（通常是双骨干，固定的开发分支和固定的公布分支），算是 TrunkBased 采纳固定公布分支的特例，在晋升团队的微服务落地能力这篇文章里介绍过，不再赘述。
GitFlow 模式是若干模式的集大成者，蕴含一个骨干分支、一个开发分支、许多的个性分支、许多的公布分支和 Hotfix 分支，以及许多繁琐的合并规定。它有一个 Git 插件，不过早就没人保护了。因为对每个阶段的每项操作定义十分明确，它已经是很多器重流程的企业眼里的香馍馍。但它应用起来并不是很容易，大量的合并抵触和对集成测试不敌对也是它被诟病最多的中央。
对，还有 GithubFlow 模式，不过这种策略无非是在 TrunkBased 的根底上，减少了集体仓库和 Pull Request 合并代码的操作，与在同一个仓库里减少集体分支的做法相似，从实用的意义来说，它更适合分布式团队。GithubFlow 也有演进版本，例如强调了多环境部署和将仓库或分支与环境关联的 GitlabFlow 模式。
要么简略粗犷如 TrunkBased，要么繁琐简单如 GitFlow。难到真没有其余抉择了吗？
另辟蹊径的 AoneFlow
在 AoneFlow 上你能看到许多其余分支模式的影子。它基本上兼顾了 TrunkBased 的“易于继续集成”和 GitFlow 的“易于治理需要”特点，同时躲避掉 GitFlow 的那些繁文缛节。
看一下具体套路。AoneFlow 只应用三种分支类型：骨干分支、个性分支、公布分支，以及三条根本规定。
规定一，开始工作前，从骨干创立个性分支。
AoneFlow 的个性分支根本借鉴 GitFlow，没有什么特别之处。每当开始一件新的工作项（比方新的性能或是待解决的问题）的时候，从代表最新已公布版本的骨干上创立一个通常以 feature/ 前缀命名的个性分支，而后在这个分支上提交代码批改。也就是说，每个工作项（能够是一个人实现，或是多集体合作实现）对应一个个性分支，所有的批改都不容许间接提交到骨干。
规定二，通过合并个性分支，造成公布分支。
AoneFlow 的公布分支设计非常奇妙，堪称整个体系的精华。GitFlow 先将曾经实现的个性分支合并回公共主线（即开发分支），而后从公共主线拉出公布分支。TrunkBased 同样是等所有须要的个性都在骨干分支上开发实现，而后从骨干分支的特定地位拉出公布分支。而 AoneFlow 的思路是，从骨干上拉出一条新分支，将所有本次要集成或公布的个性分支顺次合并过来，从而失去公布分支。公布分支通常以 release/ 前缀命名。
这条规定很简略，不过理论的玩法就相当丰盛了。
首先，公布分支的用处能够很灵便。根底玩法是将每条公布分支与具体的环境绝对应，比方 release/test 分支对应部署测试环境，release/prod 分支对应线上正式环境等等，并与流水线工具相结合，串联各个环境上的代码品质扫描和自动化测试关卡，将产出的部署包间接公布到相应环境上。进阶点的玩法是将一个公布分支对应多个环境，比方把灰度公布和正式公布串在一起，两头加上人工验收的步骤。高级的玩法呢，要是按迭代打算来关联个性分支，创立出以迭代演进的固定公布分支，再把一系列环境都串在这个公布分支的流水线上，就有点经典继续集成流水线的滋味了。再或者做一个将所有个性分支都关联在一起的公布分支，专门用于对所有提交做集成测试，就玩出了 TrunkBased 的成果。当然，这些花哨的高级玩法是我臆想的，阿里的公布分支个别都还是比拟中规中矩。
其次，公布分支的个性组成是动静的，调整起来特地容易。在一些市场瞬息万变的互联网企业，以及采纳“麻利运作”的乙方企业常常会遇到这种状况，曾经实现就期待上线的需要，随时可能因为市场策略调整或者甲方的一个长期决定，其中某个性能突然要求提早公布或者罗唆不要了。再或者是某个个性在上线前发现存在重大的开发问题，须要排除。按平常的做法，这时候就要来手工“剔代码”了，将曾经合并到开发分支或者骨干分支的相干提交一个个剔除进来，做过的同学都晓得很麻烦。在 AoneFlow 的模式下，重建公布分支只是分分钟的事，将本来的公布分支删掉，从骨干拉出新的同名公布分支，再把须要保留的各个性分支合并过去就搞定。这一系列动作可能在很大水平上实现自动化，而且不会在仓库留下一堆剔除代码的记录，洁净无污染。
此外，公布分支之间是松耦合的，这样就能够有多个集成环境别离进行不同的个性组合的集成测试，也能不便的治理各个个性进入到不同环境上部署的机会。松耦合并不代表没有相关性，因为测试环境、集成环境、预公布环境、灰度环境和线上正式环境等公布流程通常是程序进行的，在流程上能够要求只有通过前一环境验证的个性，能力传递到下一个环境做部署，造成漏斗形的个性公布流。阿里有对立平台来自动化实现个性组合在公布分支间的迁徙，在上面讲工具的局部里会再介绍。
规定三，公布到线上正式环境后，合并相应的公布分支到骨干，在骨干增加标签，同时删除该公布分支关联的个性分支。
当一条公布分支上的流水线实现了一次线上正式环境的部署，就意味着相应的性能真正的公布了，此时应该将这条公布分支合并到骨干。为了防止在代码仓库里沉积大量历史上的个性分支，还应该清理掉曾经上线局部个性分支。与 GitFlow 类似，骨干分支上的最新版本始终与线上版本统一，如果要回溯历史版本，只需在骨干分支上找到相应的版本标签即可。
除了根本规定，还有一些实际操作中不成文的技巧。比方上线后的 Hotfix，失常的解决办法应该是，创立一条新的公布分支，对应线上环境（相当于 Hotfix 分支），同时为这个分支创立长期流水线，以保障必要的公布前检查和冒烟测试可能主动执行。但其实还有一种简便办法是，将线上正式环境对应的公布分支上关联的个性分支全副清退掉，在这个公布分支上间接进行批改，改完利用现成的流水线主动公布。如果非得修一个历史版本的 Bug 怎么办呢？那就老老实实的在骨干分支找到版本标签地位，而后从那个地位创立 Hotfix 分支吧，不过因为阿里的产品大多是线上 SaaS 业务，这样的场景并不多见。
正是这些简略的规定，组成了 AoneFlow 自成一家的外围套路。
AoneFlow 中每一个看似简略的步骤都并非凭空臆造，而是经验大量产品团队重复磨砺后积攒下来的教训。接下来，我会说说 AoneFlow 的技术门槛以及阿里外部的应答之道。
AoneFlow 的体验优化
谙熟武侠之道的人都懂得，把握一个门派的看家武艺，除了要会招式，还得有深厚的内功和趁手的兵器。否则拿了辟邪剑谱，也只能望谱兴叹。
阿里团队的内功和兵器，实际上是良好的代码习惯和齐全的配套工具。
这里说的习惯，除了开发流程和代码分支的治理形式以外，还包含日常开发中的一些约定俗成的规约。阿里的许多开发规约是有“文献”记录的，次要收录在《阿里巴巴 Java 开发手册》外面。它的内容当初曾经公开了，所以早就不算是机密。
举一个具体的例子。在 AoneFlow 的流程中，每次重建公布分支的时候都会从新合并而后编译代码，产生新的部署包。然而，即便代码的内容是一样的，如果工程中依赖了一些会扭转的第三方软件包，仍然可能导致打包出的产品行为不完全一致。因而，在阿里的代码规约中就明确地指出了，用于线上公布的代码，不能够应用蕴含“SNAPSHOT 版本”（即未正式公布版本）的依赖包，从而确保每次构建出的产物都是统一的。相似这样的细节还有很多，好的开发习惯是确保软件品质的必要前提。
工具能够使得团队合作更加平滑。尽管只有弄懂原理，AoneFlow 中每个分支创立、合并、更改步骤应用单纯的 Git 命令就能玩转。但其中的一些操作（比方为每个公布分支选出失当的个性分支组合进行合并）手工执行极易出错，而且让团队的集体反复这些日常琐事的命令操作，并不是令人愉悦的事件。
在阿里外部，应用 AoneFlow 流程的团队基本上不必本人运行 Git 来解决分支的事件，而是由阿里巴巴团体外部名叫 Aone 的协同研发平台（以下简称平台）接管。这个承当团体 80% 产品从需要和用户故事提出到部署上线残缺研发流程的平台，内置了许多以服务组件的模式嵌入的研发提效工具，其中的公布组件为 AoneFlow 的用户体验添色不少。比较显著的辅助“效用”包含以下几个方面。
首先是整体流程的自动化。
因为是外部工具，平台的性能高度内聚。对于我的项目而言，从提出原始需要，将需要拆分为工作，而后依据工作在线创立个性分支，再聚合生成公布分支，同时依据模板主动创立测试环境，直到前期的运维保障都能够一站式的搞定。
这个流程曾经远远超出了代码分支治理的领域。但正是因为如此，平台对于 AoneFlow，向前做到了将个性分支和需要项关联起来，确保了个性分支的命名规范性；向后做到了将公布分支与部署行为关联起来，确保了各环境版本起源的可靠性。买通了端到端交付的任督二脉。
其次是公布分支的流水线。
作为一种流程自动化的伎俩，CI/CD 流水线是许多古代交付团队中常见的标配实际。在 AoneFlow 的代码生命周期里波及许多分支，当这些分支被创立或更新时，往往须要随同其余的一系列行为。流水线可能将这些日常开发过程中的代码分支与其所表白的深层用意（比方提交代码即进行集成测试）分割起来。特地是公布分支，AoneFlow 的每个公布分支通常关联具体的部署环境，当有新代码合并进分支时，就应该及时对代码进行检查和部署。
现实状况下，每条不同的分支都应该有与其作用相匹配的一条流水线来为它服务。AoneFlow 的公布分支是绝对固定的，因而相比 GitFlow 更易于进行继续集成。实践上任何流水线工具都可能配合 AoneFlow 应用，不过，阿里的对立平台提供流水线对代码评审、安全检查、在线部署等性能的整合，还是为 AoneFlow 在外部团队的应用优化增色不少。
还有一项很有用的辅助是分支关联的治理。
个性分支与公布分支的关联关系保护是一个 AoneFlow 特有的问题。记住每个公布分支别离来自哪些个性分支对于须要基于现有个性组合进行扭转的时候非常有意义。比方当须要将某个个性从特定公布分支退出时，通常会将除了该个性以外的其余个性所在分支进行一次合并，以替换原有的公布分支。人为的记录这些信息并不轻松，要是通过平台进行展现和辅助就会不便许多。
当某些性能组合在一个低级别的公布环境（如集成测试环境）验证实现后，咱们心愿将它的内容间接迁徙到高级别的环境（如预公布环境）对应的公布分支上。这样能够确保线上的版本肯定是通过预发验证的，预发的版本肯定是通过集成验证的，以此类推，使得各个公布分支造成串联。同样的，应用一般的 Git 命令就能实现这个操作，只不过用可视化工具会让流程更加直观。
除此以外，平台提供代码仓库各个分支情况的对立展现，包含分支所对应部署环境的机器信息、操作记录等全都和盘托出。正是这些“高附加值”的辅助，使得 AoneFlow 得以取长补短，成为阿里团队撑持简单我的项目首选的利器。
最初
代码分支模式的抉择并没有相对的正确和谬误之分，要害是与我的项目的规模和公布节奏相匹配。阿里协同研发平台在通过泛滥实际历练后，总结出了一套独创的分支治理办法，通过兼备灵便高效与简略实用的流程，保障阿里旗下泛滥产品的交付。当你还在犹豫于目不暇接的分支模式，既舍不得 GitFlow 的并行个性开发，又放不下 TrunkBased 的继续集成敌对时，AoneFlow 兴许是一个值得思考的抉择。
目前，云效对 AoneFlow 的反对曾经比拟齐备，大家可自行返回摸索。
地址：https://www.aliyun.com/produc…
【对于云效】
云原生时代一站式 DevOps 平台，数十万企业都在用。反对公共云、专有云和混合云多种部署状态，通过云原生新技术和研发新模式，助力翻新守业和数字化转型企业疾速实现研发麻利和组织麻利，打造“双敏”组织，实现多倍效力晋升。
对于咱们
理解更多对于云效 DevOps 的最新动静，可微信搜寻关注【云效】公众号；
福利：公众号后盾回复【指南】，可取得《阿里巴巴 DevOps 实际指南》&《10 倍研发效力晋升案例集》；
看完感觉对您有所帮忙别忘记点赞、珍藏和关注呦；
