多分支集成發布各種坑怎么填？| 云效-有解無憂

小明的研發團隊要發布一個版本，這個版本包含了多個功能特性，每個不同的特性之間有較強的獨立性，不同的特性由不同的開發人員或開發小組分工完成，

他們在不同的特性分支上開發，彼此相互獨立、互不影響，

一個特性開發完成后就提交測驗，這個程序不影響其他特性的正常開發，全部已完成的特性全部合并進行測驗和發布，在提交測驗，集成合并時碰到了這樣的問題：

對于某個公共模塊的修改出現了合并沖突
由于一個特性分支的集成，導致整個版本集成失敗

版本發布時間在即，為不影響整體進展，需要快速分離影響了整個集成的那個特性分支，

如果你是小明，這時你會怎么做？

小明的研發團隊又要發布一個版本，整個版本有 A、B、C、D 四個功能特性一起合并集成，分別在分支 A、B、C、D 上開發，臨近發布前，市場側通知由于某種原因功能特性 B 不能發布，也就是這次發布需要剔除分支 B，按照嚴格的集成發布策略，A、C、D 這 3 個特性分支需要重新構建，分別再經過集成測驗、預發驗證，然后到生產發布，但是，這樣做是有成本的，

如果你是小明，在效率和質量之間你會怎么選？

這兩個情景遇到的問題，在多分支并行開發集成發布中很常見，如何快速、靈活、高效又實用地解決這類問題，成為眾多小明的剛需，

阿里巴巴集團內部經歷并仍在經歷著大量多分支集成發布的實踐，這些實踐被提煉成了一套阿里的分支策略，形成了阿里分支模式，并通過公共云產品云效 Flow 對外部研發用戶輸出，

當使用云效Flow 分支模式時，小明的兩個場景問題將可以得到靈活高效地解決，

場景一：如何快速分離影響整個集成的那個特性分支

小明可以直接在再次運行分支時，洗掉已集成分支，執行流水線時將會自動進行以下操作：

基于分支管理器中設定的基礎分支（如 master），創建新的 release 分支
除了該特性分支外的其他在云效配置中的其他分支合并到 release 分支
基于 release 分支的最新內容運行流水線

場景二：發布在即需求被砍，如何平衡效率和質量？

小明發現云效分支可以按環境/流程，自由地集成，考慮到本次上線的時間對后續專案進度非常關鍵，小明選擇了跳過中間的測驗階段、預發階段直接部署到正式環境，為了最大程度避免質量風險，小明還使用了云效Flow的發布前人工審核卡點能力，最終變更沒有耽誤正常發版，也未出現任何風險，

云效 Flow 這套靈活高效的分支模式可以讓用戶只關心集成和發布哪些特性分支，而對發布分支創建和管理、分支間合并等一系列作業，托付給云效完成，

下面詳細介紹云效分支模式原理及實踐，

云效 Flow 分支規范

master 代表最新發布版本

一般情況下，master分支代表最新發布版本，當需要最新發布版本的內容時，直接取分支末端即可，

不論其他哪類分支，都建議一般從 master 分支創建，并且經常從 master 分支合并，以便跟上“潮流”，減少將來集成時的各種問題，比如代碼合并沖突，

每當軟體正式發布前，系統會確保它基于 master 最新，

每當軟體正式發布后，系統會把相應內容合并回 master，以便讓 master 分支始終代表最新發布版本，

一般來說，使用者不要直接“寫”東西到master分支，把“寫”的作業交給系統適時自動完成，

在各 feature 分支上開發

一條 feature 分支（又稱變更分支、開發分支），通常用來承載一個缺陷的修復，或者一個需求（如果不是很大的話）的開發，或者任務分解后一個任務的開發，

一般來講，基于 master 分支最新版本創建 feature 分支，然后在 feature 分支上開發、測驗，直到這個 feature 功能完成，質量 OK，準備好去集成和發布，

release 分支上的集成

release 分支用于集成和發布，基于 master 分支最新版本創建一條 release 分支，然后把想要集成的各條feature分支合并到這條release分支，進行部署和測驗作業，

如果有新的 feature 分支要加入本次集成，那就把它也合并進這條 release 分支，然后再次部署并測驗，

如果測驗發現問題，就到 feature 分支上修復，然后把它再次合并到 release 分支，把修復帶到 release 分支，

當然如果一個 feature 的問題太多太大，那干脆就放棄它，也就是說，新建一條 release 分支，把其他 feature 分支都合并過去，唯獨不再合并這條 feature 分支，

就像 master 分支一樣，release 分支也是由系統自動管理的，使用者不要直接在上面改代碼，代碼修改請總是在 feature 分支完成，

release 分支上的發布上線

當 release 分支上的質量足夠好，本次想上線的功能也都具備之后，就要考慮發布上線的問題啦，如前面講的，發布上線前，會確保它基于基礎分支（常見的如 master ）最新，而發布后會把 release 分支合并回 master，讓 master 代表最新發布版本，

以上幾節介紹的內容，見下圖：

多個環境/流程分支原理

假定要想集成發布上線，要經過日常測驗環境上的測驗這個流程，還要經過預發環境上的測驗這個流程，那么兩個流程用一條 release 分支就有些不合適，因為兩個流程可能同時在測不同的 feature 分支集合，

分支模式用這個辦法避免這個問題：每一個測驗環境，也就是每個流程，關聯它自己的 release 分支，日常測驗、預發測驗這兩個環境（也就是兩個流程），分別關聯兩條 release 分支，這樣就不會相互影響，推而廣之，為正式運行環境，也對應一條release分支，也就是說，每個環境都有對應的 release 分支，

當把集成成果從一個環境傳遞到下一個環境時，就是把一個環境下已合并到一起的 feature 分支，再往另一個環境對應的 release 分支上合并一遍……這么做有點兒笨，對于人工處理這是一個重復操作的程序，云效會幫你自動完成這一系列重復的操作，

對應下圖：