摘要：摘要阿里有很多的研發(fā)團(tuán)隊(duì)，不同事業(yè)部使用的發(fā)布流程分支策略并非整齊劃一，但總體上看是比較規(guī)整的。引言在阿里內(nèi)部，流行著許多有意思的工程實(shí)踐。比如分支管理這件事，其實(shí)屬于工具和習(xí)慣各占一半，并且頗有阿里特色的成分，適合作為一個(gè)例子。

摘要： 阿里有很多的研發(fā)團(tuán)隊(duì)，不同事業(yè)部使用的發(fā)布流程、分支策略并非整齊劃一，但總體上看是比較規(guī)整的。其中有一種主流的發(fā)布模式以及對(duì)應(yīng)的分支使用方式，稱(chēng)為“AoneFlow”。這套工作模式思路獨(dú)特，在阿里以外的地方并不多見(jiàn)。本文圍繞這些實(shí)踐，聊一聊分支管理的話(huà)題。

引言

在阿里內(nèi)部，流行著許多有意思的工程實(shí)踐。有些實(shí)踐通過(guò)工具和流程嵌在集團(tuán)的大環(huán)境里，外界不容易復(fù)制，有些實(shí)踐則是流露在大家的日常習(xí)慣里，被默默的遵守。比如分支管理這件事，其實(shí)屬于工具和習(xí)慣各占一半，并且頗有阿里特色的成分，適合作為一個(gè)例子。阿里有很多的研發(fā)團(tuán)隊(duì)，不同事業(yè)部使用的發(fā)布流程、分支策略并非整齊劃一，但總體上看是比較規(guī)整的。其中有一種主流的發(fā)布模式以及對(duì)應(yīng)的分支使用方式，稱(chēng)為“AoneFlow”。這套工作模式思路獨(dú)特，在阿里以外的地方并不多見(jiàn)。本文圍繞這些實(shí)踐，聊一聊分支管理的話(huà)題。

說(shuō)到分支管理模式，我們最耳熟能詳?shù)哪^(guò)于 TrunkBased 和 GitFlow。

TrunkBased 模式是持續(xù)集成思想所崇尚的工作方式，它由單個(gè)主干分支和許多發(fā)布分支組成，每個(gè)發(fā)布分支在特定版本的提交點(diǎn)上從主干創(chuàng)建出來(lái)，用來(lái)進(jìn)行上線部署和 Hotfix。在 TrunkBased 模式中，沒(méi)有顯性的特性分支。當(dāng)然實(shí)際上 Git 的分布式特征天生允許每個(gè)人有本地分支，TrunkBased 也并非排斥短期的特性分支存在，只不過(guò)在說(shuō)這種模式的時(shí)候，大家通常都不會(huì)明確強(qiáng)調(diào)它罷了。

雖然近年來(lái)有許多不錯(cuò)的案例，但 TrunkBased 模式并沒(méi)有一統(tǒng)天下。它的缺點(diǎn)比較明顯，太多的團(tuán)隊(duì)同時(shí)工作在主干上，到發(fā)布的時(shí)候就可能出現(xiàn)災(zāi)難（尤其是多版本并行開(kāi)發(fā)的情況）。彌補(bǔ)的措施是 FeatureToggle 以及頻繁的集成和足夠的測(cè)試覆蓋，這對(duì)開(kāi)發(fā)團(tuán)隊(duì)的能力提出了比較高的要求。目前 TrunkBased 模式主要用在不需要同時(shí)維護(hù)多個(gè)歷史版本的 SaaS 型項(xiàng)目，特別是經(jīng)過(guò)微服務(wù)改造的各種小型服務(wù)上。

TrunkBased 模式有兩種常見(jiàn)演進(jìn)版本。OneFlow 模式參考了 TrunkBased 的許多思想，對(duì)操作流程做了更嚴(yán)格的定義，增加了 Hotfix 分支等內(nèi)容。多主干模式（通常是雙主干，固定的開(kāi)發(fā)分支和固定的發(fā)布分支），算是 TrunkBased 采用固定發(fā)布分支的特例，在提升團(tuán)隊(duì)的微服務(wù)落地能力這篇文章里介紹過(guò)，不再贅述。

GitFlow 模式是若干模式的集大成者，包含一個(gè)主干分支、一個(gè)開(kāi)發(fā)分支、許多的特性分支、許多的發(fā)布分支和 Hotfix 分支，以及許多繁瑣的合并規(guī)則。它有一個(gè) Git 插件，不過(guò)早就沒(méi)人維護(hù)了。由于對(duì)每個(gè)階段的每項(xiàng)操作定義十分明確，它曾經(jīng)是很多重視流程的企業(yè)眼里的香饃饃。但它使用起來(lái)并不是很容易，大量的合并沖突和對(duì)集成測(cè)試不友好也是它被詬病最多的地方。

對(duì)，還有 GithubFlow 模式，不過(guò)這種策略無(wú)非是在 TrunkBased 的基礎(chǔ)上，增加了個(gè)人倉(cāng)庫(kù)和 Pull Request 合并代碼的操作，與在同一個(gè)倉(cāng)庫(kù)里增加個(gè)人分支的做法類(lèi)似，從實(shí)用的意義來(lái)說(shuō)，它更合適分布式團(tuán)隊(duì)。GithubFlow 也有演進(jìn)版本，例如強(qiáng)調(diào)了多環(huán)境部署和將倉(cāng)庫(kù)或分支與環(huán)境關(guān)聯(lián)的 GitlabFlow 模式。

要么簡(jiǎn)單粗暴如 TrunkBased，要么繁瑣復(fù)雜如 GitFlow。難到真沒(méi)有其他選擇了嗎？

在 AoneFlow 上你能看到許多其他分支模式的影子。它基本上兼顧了 TrunkBased 的“易于持續(xù)集成”和 GitFlow 的“易于管理需求”特點(diǎn)，同時(shí)規(guī)避掉 GitFlow 的那些繁文縟節(jié)。

看一下具體套路。AoneFlow 只使用三種分支類(lèi)型：主干分支、特性分支、發(fā)布分支，以及三條基本規(guī)則。

AoneFlow 的特性分支基本借鑒 GitFlow，沒(méi)有什么特別之處。每當(dāng)開(kāi)始一件新的工作項(xiàng)（比如新的功能或是待解決的問(wèn)題）的時(shí)候，從代表最新已發(fā)布版本的主干上創(chuàng)建一個(gè)通常以feature/前綴命名的特性分支，然后在這個(gè)分支上提交代碼修改。也就是說(shuō)，每個(gè)工作項(xiàng)（可以是一個(gè)人完成，或是多個(gè)人協(xié)作完成）對(duì)應(yīng)一個(gè)特性分支，所有的修改都不允許直接提交到主干。

AoneFlow 的發(fā)布分支設(shè)計(jì)十分巧妙，可謂整個(gè)體系的精髓。GitFlow 先將已經(jīng)完成的特性分支合并回公共主線（即開(kāi)發(fā)分支），然后從公共主線拉出發(fā)布分支。TrunkBased 同樣是等所有需要的特性都在主干分支上開(kāi)發(fā)完成，然后從主干分支的特定位置拉出發(fā)布分支。而 AoneFlow 的思路是，從主干上拉出一條新分支，將所有本次要集成或發(fā)布的特性分支依次合并過(guò)去，從而得到發(fā)布分支。發(fā)布分支通常以release/前綴命名。

這條規(guī)則很簡(jiǎn)單，不過(guò)實(shí)際的玩法就相當(dāng)豐富了。

首先，發(fā)布分支的用途可以很靈活?；A(chǔ)玩法是將每條發(fā)布分支與具體的環(huán)境相對(duì)應(yīng)，比如release/test分支對(duì)應(yīng)部署測(cè)試環(huán)境，release/prod分支對(duì)應(yīng)線上正式環(huán)境等等，并與流水線工具相結(jié)合，串聯(lián)各個(gè)環(huán)境上的代碼質(zhì)量掃描和自動(dòng)化測(cè)試關(guān)卡，將產(chǎn)出的部署包直接發(fā)布到相應(yīng)環(huán)境上。進(jìn)階點(diǎn)的玩法是將一個(gè)發(fā)布分支對(duì)應(yīng)多個(gè)環(huán)境，比如把灰度發(fā)布和正式發(fā)布串在一起，中間加上人工驗(yàn)收的步驟。高級(jí)的玩法呢，要是按迭代計(jì)劃來(lái)關(guān)聯(lián)特性分支，創(chuàng)建出以迭代演進(jìn)的固定發(fā)布分支，再把一系列環(huán)境都串在這個(gè)發(fā)布分支的流水線上，就有點(diǎn)經(jīng)典持續(xù)集成流水線的味道了。再或者做一個(gè)將所有特性分支都關(guān)聯(lián)在一起的發(fā)布分支，專(zhuān)門(mén)用于對(duì)所有提交做集成測(cè)試，就玩出了 TrunkBased 的效果。當(dāng)然，這些花哨的高級(jí)玩法是我臆想的，阿里的發(fā)布分支一般都還是比較中規(guī)中矩。

其次，發(fā)布分支的特性組成是動(dòng)態(tài)的，調(diào)整起來(lái)特別容易。在一些市場(chǎng)瞬息萬(wàn)變的互聯(lián)網(wǎng)企業(yè)，以及采用“敏捷運(yùn)作”的乙方企業(yè)經(jīng)常會(huì)遇到這種情況，已經(jīng)完成就等待上線的需求，隨時(shí)可能由于市場(chǎng)策略調(diào)整或者甲方的一個(gè)臨時(shí)決定，其中某個(gè)功能忽然要求延遲發(fā)布或者干脆不要了。再或者是某個(gè)特性在上線前發(fā)現(xiàn)存在嚴(yán)重的開(kāi)發(fā)問(wèn)題，需要排除。按往常的做法，這時(shí)候就要來(lái)手工“剔代碼”了，將已經(jīng)合并到開(kāi)發(fā)分支或者主干分支的相關(guān)提交一個(gè)個(gè)剔除出去，做過(guò)的同學(xué)都知道很麻煩。在 AoneFlow 的模式下，重建發(fā)布分支只是分分鐘的事，將原本的發(fā)布分支刪掉，從主干拉出新的同名發(fā)布分支，再把需要保留的各特性分支合并過(guò)來(lái)就搞定。這一系列動(dòng)作能夠在很大程度上實(shí)現(xiàn)自動(dòng)化，而且不會(huì)在倉(cāng)庫(kù)留下一堆剔除代碼的記錄，干凈無(wú)污染。

此外，發(fā)布分支之間是松耦合的，這樣就可以有多個(gè)集成環(huán)境分別進(jìn)行不同的特性組合的集成測(cè)試，也能方便的管理各個(gè)特性進(jìn)入到不同環(huán)境上部署的時(shí)機(jī)。松耦合并不代表沒(méi)有相關(guān)性，由于測(cè)試環(huán)境、集成環(huán)境、預(yù)發(fā)布環(huán)境、灰度環(huán)境和線上正式環(huán)境等發(fā)布流程通常是順序進(jìn)行的，在流程上可以要求只有通過(guò)前一環(huán)境驗(yàn)證的特性，才能傳遞到下一個(gè)環(huán)境做部署，形成漏斗形的特性發(fā)布流。阿里有統(tǒng)一平臺(tái)來(lái)自動(dòng)化完成特性組合在發(fā)布分支間的遷移，在下面講工具的部分里會(huì)再介紹。

當(dāng)一條發(fā)布分支上的流水線完成了一次線上正式環(huán)境的部署，就意味著相應(yīng)的功能真正的發(fā)布了，此時(shí)應(yīng)該將這條發(fā)布分支合并到主干。為了避免在代碼倉(cāng)庫(kù)里堆積大量歷史上的特性分支，還應(yīng)該清理掉已經(jīng)上線部分特性分支。與 GitFlow 相似，主干分支上的最新版本始終與線上版本一致，如果要回溯歷史版本，只需在主干分支上找到相應(yīng)的版本標(biāo)簽即可。

除了基本規(guī)則，還有一些實(shí)際操作中不成文的技巧。比如上線后的 Hotfix，正常的處理方法應(yīng)該是，創(chuàng)建一條新的發(fā)布分支，對(duì)應(yīng)線上環(huán)境（相當(dāng)于 Hotfix 分支），同時(shí)為這個(gè)分支創(chuàng)建臨時(shí)流水線，以保障必要的發(fā)布前檢查和冒煙測(cè)試能夠自動(dòng)執(zhí)行。但其實(shí)還有一種簡(jiǎn)便方法是，將線上正式環(huán)境對(duì)應(yīng)的發(fā)布分支上關(guān)聯(lián)的特性分支全部清退掉，在這個(gè)發(fā)布分支上直接進(jìn)行修改，改完利用現(xiàn)成的流水線自動(dòng)發(fā)布。如果非得修一個(gè)歷史版本的 Bug 怎么辦呢？那就老老實(shí)實(shí)的在主干分支找到版本標(biāo)簽位置，然后從那個(gè)位置創(chuàng)建 Hotfix 分支吧，不過(guò)由于阿里的產(chǎn)品大多是線上 SaaS 業(yè)務(wù)，這樣的場(chǎng)景并不多見(jiàn)。

正是這些簡(jiǎn)單的規(guī)則，組成了 AoneFlow 獨(dú)樹(shù)一幟的核心套路。

AoneFlow 中每一個(gè)看似簡(jiǎn)單的步驟都并非憑空臆造，而是經(jīng)歷大量產(chǎn)品團(tuán)隊(duì)反復(fù)磨礪后積累下來(lái)的經(jīng)驗(yàn)。接下來(lái)，我會(huì)說(shuō)說(shuō) AoneFlow 的技術(shù)門(mén)檻以及阿里內(nèi)部的應(yīng)對(duì)之道。

諳熟武俠之道的人都懂得，掌握一個(gè)門(mén)派的看家武藝，除了要會(huì)招式，還得有深厚的內(nèi)功和趁手的兵器。否則拿了辟邪劍譜，也只能望譜興嘆。

阿里團(tuán)隊(duì)的內(nèi)功和兵器，實(shí)際上是良好的代碼習(xí)慣和齊全的配套工具。

這里說(shuō)的習(xí)慣，除了開(kāi)發(fā)流程和代碼分支的管理方式以外，還包括日常開(kāi)發(fā)中的一些約定俗成的規(guī)約。阿里的許多開(kāi)發(fā)規(guī)約是有“文獻(xiàn)”記載的，主要收錄在 《阿里巴巴 Java 開(kāi)發(fā)手冊(cè)》 里面。它的內(nèi)容現(xiàn)在已經(jīng)公開(kāi)了，所以早就不算是秘密。

舉一個(gè)具體的例子。在 AoneFlow 的流程中，每次重建發(fā)布分支的時(shí)候都會(huì)重新合并然后編譯代碼，產(chǎn)生新的部署包。然而，即使代碼的內(nèi)容是一樣的，如果工程中依賴(lài)了一些會(huì)改變的第三方軟件包，依然可能導(dǎo)致打包出的產(chǎn)品行為不完全一致。因此，在阿里的代碼規(guī)約中就明確地指出了，用于線上發(fā)布的代碼，不可以使用包含“SNAPSHOT 版本”（即未正式發(fā)布版本）的依賴(lài)包，從而確保每次構(gòu)建出的產(chǎn)物都是一致的。類(lèi)似這樣的細(xì)節(jié)還有很多，好的開(kāi)發(fā)習(xí)慣是確保軟件質(zhì)量的必要前提。

工具可以使得團(tuán)隊(duì)協(xié)作更加平滑。雖然只要弄懂原理，AoneFlow 中每個(gè)分支創(chuàng)建、合并、更改步驟使用單純的 Git 命令就能玩轉(zhuǎn)。但其中的一些操作（比如為每個(gè)發(fā)布分支選出恰當(dāng)?shù)奶匦苑种ЫM合進(jìn)行合并）手工執(zhí)行極易出錯(cuò)，而且讓團(tuán)隊(duì)的個(gè)人重復(fù)這些日?，嵤碌拿畈僮?，并不是令人愉悅的事情。

在阿里內(nèi)部，使用 AoneFlow 流程的團(tuán)隊(duì)基本上不用自己運(yùn)行 Git 來(lái)處理分支的事情，而是由阿里巴巴集團(tuán)內(nèi)部名叫 Aone 的協(xié)同研發(fā)平臺(tái)（以下簡(jiǎn)稱(chēng)平臺(tái)）接管。這個(gè)承擔(dān)集團(tuán) 80% 產(chǎn)品從需求和用戶(hù)故事提出到部署上線完整研發(fā)流程的平臺(tái)，內(nèi)置了許多以服務(wù)組件的形式嵌入的研發(fā)提效工具，其中的發(fā)布組件為 AoneFlow 的用戶(hù)體驗(yàn)添色不少。比較顯著的輔助“功效”包括以下幾個(gè)方面。

由于是內(nèi)部工具，平臺(tái)的功能高度內(nèi)聚。對(duì)于項(xiàng)目而言，從提出原始需求，將需求拆分為任務(wù)，然后根據(jù)任務(wù)在線創(chuàng)建特性分支，再聚合生成發(fā)布分支，同時(shí)根據(jù)模板自動(dòng)創(chuàng)建測(cè)試環(huán)境，直到后期的運(yùn)維保障都可以一站式的搞定。

這個(gè)流程已經(jīng)遠(yuǎn)遠(yuǎn)超出了代碼分支管理的范疇。但正是因?yàn)槿绱?，平臺(tái)對(duì)于 AoneFlow，向前做到了將特性分支和需求項(xiàng)關(guān)聯(lián)起來(lái)，確保了特性分支的命名規(guī)范性；向后做到了將發(fā)布分支與部署行為關(guān)聯(lián)起來(lái)，確保了各環(huán)境版本來(lái)源的可靠性。打通了端到端交付的任督二脈。

作為一種流程自動(dòng)化的手段，CI/CD 流水線是許多現(xiàn)代交付團(tuán)隊(duì)中常見(jiàn)的標(biāo)配實(shí)踐。在 AoneFlow 的代碼生命周期里涉及許多分支，當(dāng)這些分支被創(chuàng)建或更新時(shí)，往往需要伴隨其他的一系列行為。流水線能夠?qū)⑦@些日常開(kāi)發(fā)過(guò)程中的代碼分支與其所表達(dá)的深層意圖（比如提交代碼即進(jìn)行集成測(cè)試）聯(lián)系起來(lái)。特別是發(fā)布分支，AoneFlow 的每個(gè)發(fā)布分支通常關(guān)聯(lián)具體的部署環(huán)境，當(dāng)有新代碼合并進(jìn)分支時(shí)，就應(yīng)該及時(shí)對(duì)代碼進(jìn)行檢查和部署。

理想情況下，每條不同的分支都應(yīng)該有與其作用相匹配的一條流水線來(lái)為它服務(wù)。AoneFlow 的發(fā)布分支是相對(duì)固定的，因此相比 GitFlow 更易于進(jìn)行持續(xù)集成。理論上任何流水線工具都能夠配合 AoneFlow 使用，不過(guò)，阿里的統(tǒng)一平臺(tái)提供流水線對(duì)代碼評(píng)審、安全檢查、在線部署等功能的整合，還是為 AoneFlow 在內(nèi)部團(tuán)隊(duì)的使用優(yōu)化增色不少。

特性分支與發(fā)布分支的關(guān)聯(lián)關(guān)系維護(hù)是一個(gè) AoneFlow 特有的問(wèn)題。記住每個(gè)發(fā)布分支分別來(lái)自哪些特性分支對(duì)于需要基于現(xiàn)有特性組合進(jìn)行改變的時(shí)候十分有意義。比如當(dāng)需要將某個(gè)特性從特定發(fā)布分支退出時(shí)，通常會(huì)將除了該特性以外的其他特性所在分支進(jìn)行一次合并，以替換原有的發(fā)布分支。人為的記錄這些信息并不輕松，要是通過(guò)平臺(tái)進(jìn)行展示和輔助就會(huì)方便許多。

當(dāng)某些功能組合在一個(gè)低級(jí)別的發(fā)布環(huán)境（如集成測(cè)試環(huán)境）驗(yàn)證完成后，我們希望將它的內(nèi)容直接遷移到高級(jí)別的環(huán)境（如預(yù)發(fā)布環(huán)境）對(duì)應(yīng)的發(fā)布分支上。這樣可以確保線上的版本一定是經(jīng)過(guò)預(yù)發(fā)驗(yàn)證的，預(yù)發(fā)的版本一定是經(jīng)過(guò)集成驗(yàn)證的，以此類(lèi)推，使得各個(gè)發(fā)布分支形成串聯(lián)。同樣的，使用普通的 Git 命令就能實(shí)現(xiàn)這個(gè)操作，只不過(guò)用可視化工具會(huì)讓流程更加直觀。

除此以外，平臺(tái)提供代碼倉(cāng)庫(kù)各個(gè)分支狀況的統(tǒng)一展示，包括分支所對(duì)應(yīng)部署環(huán)境的機(jī)器信息、操作記錄等全都一覽無(wú)余。正是這些“高附加值”的輔助，使得 AoneFlow 得以揚(yáng)長(zhǎng)避短，成為阿里團(tuán)隊(duì)支撐復(fù)雜項(xiàng)目首選的利器。

代碼分支模式的選擇并沒(méi)有絕對(duì)的正確和錯(cuò)誤之分，關(guān)鍵是與項(xiàng)目的規(guī)模和發(fā)布節(jié)奏相匹配。阿里協(xié)同研發(fā)平臺(tái)在經(jīng)過(guò)眾多實(shí)踐歷練后，總結(jié)出了一套獨(dú)創(chuàng)的分支管理方法，通過(guò)兼?zhèn)潇`活高效與簡(jiǎn)單實(shí)用的流程，保障阿里旗下眾多產(chǎn)品的交付。當(dāng)你還在猶豫于琳瑯滿(mǎn)目的分支模式，既舍不得 GitFlow 的并行特性開(kāi)發(fā)，又放不下 TrunkBased 的持續(xù)集成友好時(shí)，AoneFlow 也許是一個(gè)值得考慮的選擇。

作者介紹

林帆（花名金戟），阿里巴巴研發(fā)效能事業(yè)部技術(shù)專(zhuān)家。

閱讀原文