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

收藏待读

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

背景

目前,互聯網產品呈現出高頻優化迭代的趨勢,需求方希望儘早地看到結果,並給予及時反饋,所以技術團隊需要用「小步快跑」的姿勢來做產品,儘早地交付新版本。基於以上背景,美團客戶端研發平台適時地推行了單周發版的迭代策略。單周版本迭代的優點可以概括為三個方面:更快地驗證產品創意是否符合預期,更靈活地上線節奏,更早地修複線上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年加入美團,目前主要負責大交通業務的客戶端架構、版本管理及相關工作。

發現文章有錯誤、對內容有疑問,都可以關注美團技術團隊微信公眾號(meituantech),在後台給我們留言。我們每周會挑選出一位熱心小夥伴,送上一份精美的小禮品。快來掃碼關注我們吧!

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

原文 : 美團技術團隊

相關閱讀

免责声明:本文内容来源于美團技術團隊,已注明原文出处和链接,文章观点不代表立场,如若侵犯到您的权益,或涉不实谣言,敬请向我们提出检举。