客戶端單週發版下的多分支自動化管理與實踐

背景

目前，互聯網產品呈現出高頻優化迭代的趨勢，需求方但願儘早地看到結果，並給予及時反饋，因此技術團隊須要用「小步快跑」的姿式來作產品，儘早地交付新版本。基於以上背景，美團客戶端研發平臺適時地推行了單週發版的迭代策略。單週版本迭代的優勢能夠歸納爲三個方面：更快地驗證產品創意是否符合預期，更靈活地上線節奏，更早地修復線上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分支的最新代碼，保證下一個即將發佈的版本的功能代碼的完整性。

上面的流程描述可能有些複雜，下面是簡化的流程圖，每一個版本都有本身的生命週期：

1. 從Stage建立一個Release分支；
2. 進入開發階段；
3. 若是Stage分支有變化，同步Stage分支；
4. 打包測試；
5. 測試經過，發佈線上；
6. 發佈線上以後，合回Stage分支。

爲了適應單週發版，新的開發流程也引入了不少新的挑戰。例以下圖所示的一個Branch分支中涉及的六個關鍵點：建立分支、合入主幹、主幹變化通知、Merge主幹變化、檢測主幹同步、未同步攔截，除了這些還要考慮多倉庫同步操做的問題，還有熱修復版本的管理方式的問題。可否把這些關鍵節點合理的規範和把控起來，是咱們當前應對多分支並行開發的主要難點：

如何更高效的解決這些問題呢？結合咱們當前使用的工具：Git + Atlassian Stash 代碼倉庫管理工具；Jenkins Build打包工具；大象（美團內部通信工具）內網通訊工具。目前這三個開發工具已經很是成熟、穩定，而且接口豐富易於擴展，咱們須要配合當前單週發版的分支管理模式，利用這些工具來進行擴展開發，正所謂「要站在巨人的肩膀上」。

1. 建立分支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的建立，即採用統一的命名規範，而且同時升級版本號。這就解決了建立分支的難點，實現了自動化建立分支，而且實現了規範化命名。

1. 如何知道Stage分支有變化，變化後須要作什麼，不作會怎樣？

一個好的開發習慣，就是天天寫碼以前都同步主分支，可是仍是須要一個機制來確保同步。這裏作了三個措施來確保各個分支和Stage是保持同步的：一個通知，一個警告，一次攔截。這三個步驟解決主幹變化通知、檢測主幹同步、未同步攔截的問題。

一個通知：具體路徑以下，創建了一個內部推送公衆帳號和一個Jenkins監聽Job，當全部交通業務倉庫Stage分支有代碼改動，通知全部對應的開發人員，該倉庫有代碼變化，請及時合入。

一次警告：本地開發過程當中，每次提交代碼到遠端倉庫時，會觸發一個Stage分支代碼同步檢測的腳本，若是發現未同步，會經過內部通信系統通知提交者存在未同步主分支問題。但這裏目前並不作強制攔截，保證分支代碼開發的總體流暢性。

最終攔截：在開發分支打包的過程當中強制攔截，最終功能代碼上線仍是須要打包操做。在打包操做時統一收口，因爲以前打包也是在Jenkins上來完成的，這裏咱們也是經過在打包Jenkins上接入了分支合併檢測的插件，這樣每次打包時會再次檢測和主分支的同步狀況。若是發現未同步則打包失敗，確保每次發版都包含當前線上已有代碼的功能，防止新版本丟失功能。

1. 如何合併分支，如何保證漏合？

和上面提到的第一個如何建立分支的問題相似，經過Jenkins Job來進行批量操做，能夠一鍵建立全部分支的Pull Request；在每一個版本發版以前，統一進行一次打包，合入美團的主分支，防止多個倉庫有漏合的狀況。

1. 公共基礎庫版本策略？

公共基礎和業務分支保持一樣的策略，經過批處理腳本同時創建分支，合併分支，監聽分支變化，須要注意的是，每次版本升級，公共基礎庫也須要同步的打包，而且強制業務庫升級。否則，若是基礎倉庫存在接口變更，有的業務升級了，有的業務沒升級，最終會致使沒法合入主分支，進而沒法打出App包。

1. 熱修復的版本管理策略？

熱修復確實是一種很是規的處理方式。從原則上來說，熱修復須要在對應的Release分支上進行修改，而後把修改合入Stage分支，同時須要同步到其它正在開發的分支。實際的處理須要根據具體狀況來分析，是否須要對線上多個版本熱修復。若是多版本都要修復就不能再合入Stage分支，不然會致使Stage分支衝突，若是把Stage分支合入須要熱修復的其它分支，會把線上當前最新代碼帶入歷史舊版本，會致使版本兼容性問題。最終執行起來可能仍是對熱修復版本進行單獨處理，不必定要進行Stage主分支的同步，熱修復的版本管理成本會比較高，更多的須要人工介入。

將來展望

目前總體的分支發版流程已經基本完成，如今已經穩定運行了10個小版本，同時沒有出現由於分支管理問題而引起的線上問題。

不過，當前總體流程的自動化程度還有待提升，每週須要人工去觸發，不少代碼合併過程當中的衝突問題還須要人工去解決。將來咱們但願可以自動化地根據平臺的版本號自動建立分支，而且對於一些簡單的衝突問題擁有自動化的處理能力。隨着單週發版的不斷成熟，將來對於持續交付能力也將不斷提高，發版節奏能夠不限於單週，一週兩版或是更快的發版節奏也成爲一種新的可能。

做者介紹

• 王坤，美團客戶端開發工程師，2016年加入美團，目前主要負責大交通業務的客戶端架構、版本管理及相關工做。