客戶端單週發版下的多分支自動化管理與實踐
背景
目前，網際網路產品呈現出高頻優化迭代的趨勢，需求方希望儘早地看到結果，並給予及時反饋，所以技術團隊需要用“小步快跑”的姿勢來做產品，儘早地交付新版本。基於以上背景，美團客戶端研發平臺適時地推行了單週發版的迭代策略。單週版本迭代的優點可以概括為三個方面：更快地驗證產品創意是否符合預期，更靈活地上線節奏，更早地修復線上Bug。
首先說一下美團平臺的發版策略，主要變更點是由之前的每四周發一版改為每週都有發版。具體對比如下：
- （舊）三週迭代指的是2周開發+1周半測試，依賴固定的排期和測試時間，如果錯過排期，則需要等待至少20天方可跟著下個版本迭代釋出，線上驗證產品效果的時間偏長。具體示例描述如下：
- （新）單週版本迭代指一週一發版，單週迭代版本排期、測試不再依賴固定時間節點，需求開發並測試完成，就可以搭乘最近一週的發版“小火車”，跟版釋出直接上線。對於一般需求而言，這將會大大縮短迭代時間。
業務方研發人員的痛點
在之前按月發版的迭代節奏下，基本上所有的需求都屬於序列開發，每個版本的開發流程比較固定。從“評審-開發-提測-灰度-上線”各個環節都處於一個固定的時間點來順序執行，開發人力資源的協調方式也相對簡單。全面推進單週發版之後，並不能把所有需求壓縮到5天之內開發完成，而是會存在大量的並行開發的場景，之前的固定時間節點全部被打破，由固定週期變成了動態化調配，這給業務方的需求管理和研發人員人力管理都帶來了指數式複雜度的提升。一旦進入並行開發，需求之間會產生衝突和依賴關係，版本程式碼也會隨之產生衝突和依賴，這也大大提高了開發過程中的分支管理成本，如何規範化管理分支，降低分支衝突，把控程式碼質量，是本文接下來要討論的重點。
下面描述了幾種典型的單週發版帶來的問題：
- 業務需求開發週期不固定，會存在大量的多版本、多需求並行開發。平臺只提供了單週發版的基礎策略，每5天發一版，業務方完成需求即可搭車發版。
對於各業務方來說，需求開發往往並不是都能在5天內完成，一般需求在5~10天左右，在之前序列發版模式下這個問題其實也存在，但並不突出，在單週發版的前提下，都要面臨跨版本開發，意味著多個版本多個需求會同步並行開發，這給業務方的分支管理帶來了極大的挑戰。
- 業務方架構複雜，倉庫依賴多，單週發版分支建立合併維護成本大。
交通業務線涉及火車票、國內機票、國際機票多條業務線，程式碼倉庫除了業務線的獨立倉庫，還有交通首頁，交通公共倉庫，RN倉庫等多個倉庫，Android端6個Git倉庫，iOS端5個倉庫，RN5個倉庫，共計16個Git倉庫。
多倉庫頻繁發版分支程式碼存在安全風險，容易漏合程式碼，沖掉線上程式碼。
- 業務線自身的公共基礎庫需求變動頻繁。也需要具備單週發版的能力。
例如交通公共基礎倉庫，承載了很多交通業務線的UI功能元件，這些公共元件的業務變化頻繁，公共基礎倉庫變化的同時，可能會對使用元件的業務產生影響，需要同步的升級發版。美團平臺的策略是公共服務元件每四個小版本統一升級一次，但對業務方自身元件這種策略限制較大，還是需要公共元件也要具備隨時發版的能力。
單週發版分支管理解決方案
針對上面提出的問題，交通客戶端團隊通過技術培訓、流程優化、關鍵點檢測、自動化處理等方式保證分支程式碼的安全。技術培訓主要是加強技術人員分支管理的基本知識，Git的正確使用方法，這裡不做過多描述。本文主要討論關鍵點檢測，以及如何進行自動化的分支管理。
在實施單週發版之前，業務方程式碼倉庫只有兩個分支，Develop分支，即開發分支；Stage分支，即發版分支；開發流程基本在序列開發模式，每個版本10天開發，8天測試，然後進入下一版本的開發。
這種方式只能適用於節奏固定的長週期開發方式，對於多版本並行開發來說，有點力不從心，顯然已經不能承載當前更靈活的發版節奏。
針對這些問題，我們推出瞭如下分支管理結構。總的來說，就是廢除之前作為開發分支的Develop分支，建立對應的Release發版分支，每個版本打包從Release分支直接打包；同時Stage分支不再承擔打包職責，而是作為一個主幹分支實時同步所有已釋出上線的功能，Stage分支更像一個“母體”，孵化出Release分支和其它Feature分支；當Release分支測試通過、並且發版上線之後，再合入到Stage分支，此時所有正在開發中的其它分支都需要同步Stage分支的最新程式碼，保證下一個即將釋出的版本的功能程式碼的完整性。
上面的流程描述可能有些複雜，下面是簡化的流程圖，每個版本都有自己的生命週期：
- 從Stage建立一個Release分支；
- 進入開發階段；
- 如果Stage分支有變化，同步Stage分支；
- 打包測試；
- 測試通過，釋出線上；
- 釋出線上之後，合回Stage分支。
為了適應單週發版，新的開發流程也引入了很多新的挑戰。例如下圖所示的一個Branch分支中涉及的六個關鍵點：建立分支、合入主幹、主幹變化通知、Merge主幹變化、檢測主幹同步、未同步攔截，除了這些還要考慮多倉庫同步操作的問題，還有熱修復版本的管理方式的問題。能否把這些關鍵節點合理的規範和把控起來，是我們當前應對多分支並行開發的主要難點：
如何更高效的解決這些問題呢？結合我們當前使用的工具：Git + Atlassian Stash 程式碼倉庫管理工具；Jenkins Build打包工具；大象（美團內部通訊工具）內網通訊工具。目前這三個開發工具已經非常成熟、穩定，並且介面豐富易於擴充套件，我們需要配合當前單週發版的分支管理模式，利用這些工具來進行擴充套件開發，正所謂“要站在巨人的肩膀上”。
- 建立分支Release分支如何建立，何時建立，分支命名規範定義如何約束？
建立Release分支，本質上是從Stage新建一個分支，當前提前一個週期建立新的發版分支，例如在10.1.1版本Release後，建立10.1.3版本的分支，此時10.1.2版本處於開發測試階段。業務方所有的分支命名和平臺的分支命名保持一致，採用Release/x.x.x的格式，但同時需要升級成為即將釋出的Release版本號，例如10.1.3。
現在交通業務線多達十幾個倉庫，每個倉庫每週都要操作一次需要耗費大量人力。之前每個分支的建立都是通過Stash或者手工建立，能不能自動化批處理的建立呢？答案是肯定的。對此，我們採用了Jenkins的方式，需要建立一個Jenkins Job, 基本原理就是通過命令列的方式進行Branch的建立，然後通過Job管理，批處理建立所有倉庫的Release分支，這樣就收斂了Branch的建立，即採用統一的命名規範，並且同時升級版本號。這就解決了建立分支的難點，實現了自動化建立分支，並且實現了規範化命名。
- 如何知道Stage分支有變化，變化後需要做什麼，不做會怎樣？
一個好的開發習慣，就是每天寫碼之前都同步主分支，但是還是需要一個機制來確保同步。這裡做了三個措施來確保各個分支和Stage是保持同步的：一個通知，一個警告，一次攔截。這三個步驟解決主幹變化通知、檢測主幹同步、未同步攔截的問題。
**一個通知：**具體路徑如下，建立了一個內部推送公眾賬號和一個Jenkins監聽Job，當所有交通業務倉庫Stage分支有程式碼改動，通知所有對應的開發人員，該倉庫有程式碼變化，請及時合入。
**一次警告：**本地開發過程中，每次提交程式碼到遠端倉庫時，會觸發一個Stage分支程式碼同步檢測的指令碼，如果發現未同步，會通過內部通訊系統通知提交者存在未同步主分支問題。但這裡目前並不做強制攔截，保證分支程式碼開發的整體流暢性。
**最終攔截：**在開發分支打包的過程中強制攔截，最終功能程式碼上線還是需要打包操作。在打包操作時統一收口，由於之前打包也是在Jenkins上來完成的，這裡我們也是通過在打包Jenkins上接入了分支合併檢測的外掛，這樣每次打包時會再次檢測和主分支的同步情況。如果發現未同步則打包失敗，確保每次發版都包含當前線上已有程式碼的功能，防止新版本丟失功能。
- 如何合併分支，如何保證漏合？
和上面提到的第一個如何建立分支的問題類似，通過Jenkins Job來進行批量操作，可以一鍵建立所有分支的Pull Request；在每個版本發版之前，統一進行一次打包，合入美團的主分支，防止多個倉庫有漏合的情況。
- 公共基礎庫版本策略？
公共基礎和業務分支保持同樣的策略，通過批處理指令碼同時建立分支，合併分支，監聽分支變化，需要注意的是，每次版本升級，公共基礎庫也需要同步的打包，並且強制業務庫升級。不然，如果基礎倉庫存在介面變動，有的業務升級了，有的業務沒升級，最終會導致無法合入主分支，進而無法打出App包。
- 熱修復的版本管理策略？
熱修復確實是一種非常規的處理方式。從原則上來講，熱修復需要在對應的Release分支上進行修改，然後把修改合入Stage分支，同時需要同步到其它正在開發的分支。實際的處理需要根據具體情況來分析，是否需要對線上多個版本熱修復。如果多版本都要修復就不能再合入Stage分支，否則會導致Stage分支衝突，如果把Stage分支合入需要熱修復的其它分支，會把線上當前最新程式碼帶入歷史舊版本，會導致版本相容性問題。最終執行起來可能還是對熱修復版本進行單獨處理，不一定要進行Stage主分支的同步，熱修復的版本管理成本會比較高，更多的需要人工介入。
未來展望
目前整體的分支發版流程已經基本完成，現在已經穩定運行了10個小版本，同時沒有出現因為分支管理問題而引發的線上問題。
不過，當前整體流程的自動化程度還有待提高，每週需要人工去觸發，很多程式碼合併過程中的衝突問題還需要人工去解決。未來我們希望能夠自動化地根據平臺的版本號自動建立分支，並且對於一些簡單的衝突問題擁有自動化的處理能力。隨著單週發版的不斷成熟，未來對於持續交付能力也將不斷提升，發版節奏可以不限於單週，一週兩版或是更快的發版節奏也成為一種新的可能。
作者介紹
- 王坤，美團客戶端開發工程師，2016年加入美團，目前主要負責大交通業務的客戶端架構、版本管理及相關工作。