大眾點評千人移動研發團隊怎樣做持續集成？

最新 07-17

【IT168 技術】

一、背景

美團點評是中國領先的生活服務電子商務平台，為數億消費者和幾百萬商家提供服務。秉承「幫大家吃得更好，生活更好」的使命，我們的業務覆蓋了超過200個品類和2800個市縣，旗下生活服務線上交易平台美團、生活服務線上探索平台大眾點評、即時配送服務美團外賣和共享單車服務摩拜都是中國家喻戶曉的品牌。

隨著各業務的蓬勃發展，大眾點評移動研發團隊從當初各自為戰的「小作坊」已經發展成為可以協同作戰的、擁有千人規模的「正規軍」。我們的移動項目架構為了適應業務發展也發生了天翻地覆的變化，這對移動持續集成提出更高的要求，而整個移動研發團隊也迎來了新的機遇和挑戰。

二、問題與挑戰

當前移動客戶端的組件庫超過600個，多個移動項目的代碼量達到百萬行級別，每天有幾百次的發版集成需求。保證近千名移動研發人員順利進行開發和集成，這是我們部門的重要使命。但是，前進的道路從來都不是平坦的，在通向目標的大道上，我們還面臨著很多問題與挑戰，主要包括以下幾個方面：

項目依賴複雜

上圖僅僅展示了我們移動項目中一小部分組件間的依賴關係，可以想像一下，這600多個組件之間的依賴關係，就如同一個城市複雜的道路交通網讓人眼花繚亂。這種組件間錯綜複雜的依賴關係也必然會導致兩個嚴重問題：

第一，如果某個業務需要修改代碼，極有可能會影響到其它業務，牽一髮而動全身，進而會讓很多研發同學工作時戰戰兢兢，做項目更加畏首畏尾。

第二，管理這些組件間繁瑣的依賴關係也是一件令人頭疼的事情，現在平均每個組件的依賴數有70多個，最多的甚至達到了270多個，如果依靠人工來維護這些依賴關係，難如登天。

研發流程瑣碎

移動研發要完成一個完整功能需求，除了代碼開發以外，需要經歷組件發版、組件集成、打包、測試。如果測試發現Bug需要進行修復，然後再次經歷組件發版、組件集成、打包、測試，直到測試通過交付產品。研發同學在整個過程中需要手動提交MR、手動升級組件、手動觸發打包以及人工實時監控流程的狀態，如此研發會被頻繁打斷來跟蹤處理過程的銜接，勢必嚴重影響開發專註度，降低研發生產力。

構建速度慢

目前大眾點評的iOS項目構建時間，從兩年前的20分鐘已經增長到現在的60分鐘以上，Android項目也從5分鐘增長到11分鐘，移動項目構建時間的增長，已經嚴重影響了移動端開發集成的效率。而且隨著業務的快速擴張，項目代碼還在持續不斷的增長。為了適應業務的高速發展，尋求行之有效的方法來加快移動項目的構建速度，已經變得刻不容緩。

App質量保證

評價App的性能質量指標有很多，例如：CPU使用率、內存佔用、流量消耗、響應時間、線上Crash率、包體等等。其中線上Crash直接影響著用戶體驗，當用戶使用App時如果發生閃退，他們很有可能會給出「一星」差評;而包體大小是影響新用戶下載App的重要因素，包體過大用戶很有可能會對你的App失去興趣。因此，降低App線上Crash率以及控制App包體大小是每個移動研發都要追求的重要目標。

項目依賴複雜、研發流程瑣碎、構建速度慢、App質量保證是每個移動項目在團隊、業務發展壯大過程中都會遇到的問題，本文將根據大眾點評移動端多年來積累的實踐經驗，一步步闡述我們是如何在實戰中解決這些問題的。

三、MCI架構

MCI(Mobile continuous integration)是大眾點評移動端團隊多年來實踐總結出來的一套行之有效的架構體系。它能實際解決移動項目中依賴複雜、研發流程瑣碎、構建速度慢的問題，同時接入MCI架構體系的移動項目能真正有效實現App質量的提升。

MCI完整架構體系如下圖所示：

MCI架構體系包含移動CI平台、流程自動化建設、靜態檢查體系、日誌監控&分析、信息管理配置，另外MCI還採取二進位集成等措施來提升MCI的構建速度。

構建移動CI平台

我們通過構建移動CI平台，來保證移動研發在項目依賴極其複雜的情況下，也能互不影響完成業務研發集成;其次我們設計了合理的CI策略，來幫助移動研發人員走出令人望而生畏的依賴關係管理的「泥潭」。

流程自動化建設

在構建移動CI平台的基礎上，我們對MCI流程進行自動化建設來解決研發流程瑣碎問題，從而解放移動研發生產力。

提升構建速度

在CI平台保證集成正確性的情況下，我們通過依賴扁平化以及優化集成方式等措施來提升MCI的構建速度，進一步提升研發效率。

靜態檢查體系

我們建立一套完整自研的靜態檢查體系，針對移動項目的特點，MCI上線全方位的靜態檢查來促進App質量的提升。

日誌監控&分析

我們對MCI體系的完整流程進行日誌落地，方便問題的追溯與排查，同時通過數據分析來進一步優化MCI的流程以及監控移動App項目的健康狀況。

信息管理配置

最後，為了方便管理接入MCI的移動項目，我們建設了統一的項目信息管理配置平台。

接下來，我們將依次詳細探討MCI架構體系是如何一步步建立，進而解決我們面臨的各種問題。

四、構建移動CI平台

搭建移動CI平台

我們對目前業內流行的CI系統，如：Travis CI、 CircleCI、Jenkins、GitLab CI調研後，針對移動項目的特點，綜合考慮代碼安全性、可擴展性及頁面可操作性，最終選擇基於GitLab CI搭建移動持續集成平台，當然我們也使用Jenkins做一些輔助性的工作。MCI體系的CI核心架構如下圖所示：

名詞解釋：

GitLab CI：GitLab CI是GitLab Continuous Integration(GitLab持續集成)的簡稱。

Runner：Runner是GitLab CI提供註冊CI伺服器的介面。

Pipeline：可以理解為流水線，包含CI不同階段的不同任務。

Trigger：觸發器，Push代碼或者提交Merge Request等操作會觸發相應的觸發器以進入下一流程。

該架構的優勢是可擴展性強、可定製、支持並發。首先CI伺服器可以任意擴展，除了專用的伺服器可以作為CI伺服器，普通個人PC機也可以作為CI伺服器(缺點是性能比伺服器差，任務執行時間較長);其次每個集成任務的Pipeline是支持可定製的，託管在MCI的集成項目可以根據自身需求定製與之匹配的Pipeline;最後，每個集成項目的任務執行是可並發的，因此各業務線間可以互不干擾的進行組件代碼集成。

CI流程設計

一次完整的組件集成流程包含兩個階段：組件庫發版和向目標App工程集成。如下圖所示：

第一階段，在日常功能開發完畢後，研發提PR到指定分支，在對代碼進行Review、組件庫編譯及靜態檢查無誤後，自動發版進入組件池中。所有進入組件池中的組件均可以在不同App項目中復用。

第二階段，研髮根據需要將組件合入指定App工程。組件A本身的正確性已經在第一階段的組件庫發版中驗證，第二階段是檢查組件A的改變是否對目標App中原有依賴它的其它組件造成影響。所以首先需要分析組件A被目標App中哪些組件所依賴，目標App工程按照各自的准入標準，對合入的組件庫進行編譯和靜態分析，待檢查無誤後，最終合入發布分支。

通過組件發版和集成兩階段的CI流程，組件將被正確集成到目標項目中。而對於存在問題的組件則會阻擋在項目之外，因此不會影響其它業務的正常開發和發版集成，各業務研發流程獨立可控。

設計合理的CI策略

組件的發版和集成能否通過CI檢查，取決於組件當前的依賴以及組件本身是否與目標項目兼容。移動研發需要對組件當前依賴有足夠的了解才能順利完成發版集成，為了減小組件依賴管理的複雜度，我們設計了合理的發版集成策略來幫助移動研發走出繁瑣的版本依賴管理的困境。

組件集成策略

每個組件都有自己的依賴項，不同組件可能會依賴同一個組件，組件向目標項目集成過程中會面臨如下一些問題：

版本集成衝突：組件在集成過程中某個依賴項與目標項目中現有依賴的版本號存在衝突。

App測試包不穩定：組件依賴項的版本發生變化導致在不同時刻打出不同依賴項的App測試包。

頻繁的版本集成衝突會導致業務協同開發集成效率低下，App測試包的不穩定性會給研發追蹤問題帶來極大的困擾。問題的根源在於目標項目使用每個組件的依賴項來進行集成。因此我們通過在集成項目中顯示指定組件版本號以及禁止動態依賴的方式，保證了App測試包的穩定性和可靠性，同時也解決了組件版本集成衝突問題。

組件發版策略

組件向組件池發版也一樣會涉及依賴項的管理，簡單粗暴的方法是指定所有依賴項的版本號，這樣做的好處是直觀明了，但研發需要對不同版本依賴項的功能有足夠的了解。正如組件集成策略中所述，集成項目中每個組件的版本都是顯示指定並且唯一確定的，組件中指定依賴項的版本號在集成項目中並不起作用。所以我們在組件發版時採用自動依賴組件池中最新版本的方式。這樣設計的好處在於：

避免移動研發對版本依賴關係的處理。

給基礎組件的變更迭代提供了強有力的推動機制。

當基礎組件庫的介面和設計發生較大變化時，可以強有力的推動業務層組件做相應適配，保證了在高度解耦的項目架構下保持高度的敏捷性。但這種能力不能濫用，需要根據業務迭代周期合理安排，並做好提前通知動員工作。

五、流程自動化建設

研發流程瑣碎的主要原因是研發需要人工參與持續集成中每一步過程，一旦我們把移動研發從持續集成過程中解放出來，自然就能提高研發生產力。我們通過項目集成發布流程自動化以及優化測試包分發來優化MCI流程。

項目集成流程託管

研發流程中的組件發版、組件集成與App打包都是持續集成中的標準化流程，我們通過流程託管工具來完成這幾個步驟的自動銜接，研發同學只需關注代碼開發與Bug修復。

流程託管工具實現方案如下：

自動化流程執行：通過託管隊列實現任務自動化順序執行，webhook實現流程狀態的監聽。

關鍵節點通知：在關鍵性節點流程執行成功後發送通知，讓研發對流程狀態瞭然於胸。

流程異常通知：一旦持續集成流程執行異常，例如項目編譯失敗、靜態檢查沒通過等，第一時間通知研發及時處理。

打包發布流程託管

無論iOS還是Android，在發布App包到市場前都需要做一系列處理，例如iOS需要導出ipa包進行備份，保存符號表來解析線上Crash，以及上傳ipa包到iTC(iTunes Connect);而Android除了包備份，保存Mapping文件解析線上Crash外，還要發布App包到不同的渠道，整個打包發布流程更加複雜繁瑣。

在沒有MCI流程託管以前，每到App發布日，研發同學就如臨大敵守在打包機器前，披荊斬棘，過五關斬六將，直到所有App包被「運送」到指定地點，搞得十分疲憊。如同項目集成流程託管一樣，我們把整個打包發布流程做了全流程託管，無人值守的自動打包發布方式解放了研發同學，研發同學再也不用每次都披星戴月，早出晚歸，跪鍵盤了(捂臉)。

包分發流程建設