一、背景

美團(tuán)是全球最大的互聯(lián)網(wǎng)+生活服務(wù)平臺(tái)，為3.2億活躍用戶和500多萬(wàn)的優(yōu)質(zhì)商戶提供一個(gè)連接線上與線下的電子商務(wù)服務(wù)。秉承“幫大家吃得更好，生活更好”的使命，我們的業(yè)務(wù)覆蓋了超過200個(gè)品類和2800個(gè)城區(qū)縣網(wǎng)絡(luò)，在餐飲、外賣、酒店旅游、麗人、家庭、休閑娛樂等領(lǐng)域具有領(lǐng)先的市場(chǎng)地位。

隨著各業(yè)務(wù)的蓬勃發(fā)展，大眾點(diǎn)評(píng)移動(dòng)研發(fā)團(tuán)隊(duì)從當(dāng)初各自為戰(zhàn)的“小作坊”已經(jīng)發(fā)展成為可以協(xié)同作戰(zhàn)的、擁有千人規(guī)模的“正規(guī)軍”。我們的移動(dòng)項(xiàng)目架構(gòu)為了適應(yīng)業(yè)務(wù)發(fā)展也發(fā)生了天翻地覆的變化，這對(duì)移動(dòng)持續(xù)集成提出更高的要求，而整個(gè)移動(dòng)研發(fā)團(tuán)隊(duì)也迎來了新的機(jī)遇和挑戰(zhàn)。

二、問題與挑戰(zhàn)

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

項(xiàng)目依賴復(fù)雜

上圖僅僅展示了我們移動(dòng)項(xiàng)目中一小部分組件間的依賴關(guān)系，可以想象一下，這600多個(gè)組件之間的依賴關(guān)系，就如同一個(gè)城市復(fù)雜的道路交通網(wǎng)讓人眼花繚亂。這種組件間錯(cuò)綜復(fù)雜的依賴關(guān)系也必然會(huì)導(dǎo)致兩個(gè)嚴(yán)重的問題，第一，如果某個(gè)業(yè)務(wù)需要修改代碼，極有可能會(huì)影響到其它業(yè)務(wù)，牽一發(fā)而動(dòng)全身，進(jìn)而會(huì)讓很多研發(fā)同學(xué)工作時(shí)戰(zhàn)戰(zhàn)兢兢，做項(xiàng)目更加畏首畏尾；第二，管理這些組件間繁瑣的依賴關(guān)系也是一件令人頭疼的事情，現(xiàn)在平均每個(gè)組件的依賴數(shù)有70多個(gè)，最多的甚至達(dá)到了270多個(gè)，如果依靠人工來維護(hù)這些依賴關(guān)系，難如登天。

研發(fā)流程瑣碎

移動(dòng)研發(fā)要完成一個(gè)完整功能需求，除了代碼開發(fā)以外，需要經(jīng)歷組件發(fā)版、組件集成、打包、測(cè)試。如果測(cè)試發(fā)現(xiàn)Bug需要進(jìn)行修復(fù)，然后再次經(jīng)歷組件發(fā)版、組件集成、打包、測(cè)試，直到測(cè)試通過交付產(chǎn)品。研發(fā)同學(xué)在整個(gè)過程中需要手動(dòng)提交MR、手動(dòng)升級(jí)組件、手動(dòng)觸發(fā)打包以及人工實(shí)時(shí)監(jiān)控流程的狀態(tài)，如此研發(fā)會(huì)被頻繁打斷來跟蹤處理過程的銜接，勢(shì)必嚴(yán)重影響開發(fā)專注度，降低研發(fā)生產(chǎn)力。

構(gòu)建速度慢

目前大眾點(diǎn)評(píng)的iOS項(xiàng)目構(gòu)建時(shí)間，從兩年前的20分鐘已經(jīng)增長(zhǎng)到現(xiàn)在的60分鐘以上，Android項(xiàng)目也從5分鐘增長(zhǎng)到11分鐘，移動(dòng)項(xiàng)目構(gòu)建時(shí)間的增長(zhǎng)，已經(jīng)嚴(yán)重影響了移動(dòng)端開發(fā)集成的效率。而且隨著業(yè)務(wù)的快速擴(kuò)張，項(xiàng)目代碼還在持續(xù)不斷的增長(zhǎng)。為了適應(yīng)業(yè)務(wù)的高速發(fā)展，尋求行之有效的方法來加快移動(dòng)項(xiàng)目的構(gòu)建速度，已經(jīng)變得刻不容緩。

App質(zhì)量保證

評(píng)價(jià)App的性能質(zhì)量指標(biāo)有很多，例如：CPU使用率、內(nèi)存占用、流量消耗、響應(yīng)時(shí)間、線上Crash率、包體等等。其中線上Crash直接影響著用戶體驗(yàn)，當(dāng)用戶使用App時(shí)如果發(fā)生閃退，他們很有可能會(huì)給出“一星”差評(píng)；而包體大小是影響新用戶下載App的重要因素，包體過大用戶很有可能會(huì)對(duì)你的App失去興趣。因此，降低App線上Crash率以及控制App包體大小是每個(gè)移動(dòng)研發(fā)都要追求的重要目標(biāo)。

項(xiàng)目依賴復(fù)雜、研發(fā)流程瑣碎、構(gòu)建速度慢、App質(zhì)量保證是每個(gè)移動(dòng)項(xiàng)目在團(tuán)隊(duì)、業(yè)務(wù)發(fā)展壯大過程中都會(huì)遇到的問題，本文將根據(jù)大眾點(diǎn)評(píng)移動(dòng)端多年來積累的實(shí)踐經(jīng)驗(yàn)，一步步闡述我們是如何在實(shí)戰(zhàn)中解決這些問題的。

三、MCI架構(gòu)

MCI（Mobile continuous integration）是大眾點(diǎn)評(píng)移動(dòng)端團(tuán)隊(duì)多年來實(shí)踐總結(jié)出來的一套行之有效的架構(gòu)體系。它能實(shí)際解決移動(dòng)項(xiàng)目中依賴復(fù)雜、研發(fā)流程瑣碎、構(gòu)建速度慢的問題，同時(shí)接入MCI架構(gòu)體系的移動(dòng)項(xiàng)目能真正有效實(shí)現(xiàn)App質(zhì)量的提升。

MCI完整架構(gòu)體系如下圖所示：

MCI架構(gòu)體系包含移動(dòng)CI平臺(tái)、流程自動(dòng)化建設(shè)、靜態(tài)檢查體系、日志監(jiān)控&分析、信息管理配置，另外MCI還采取二進(jìn)制集成等措施來提升MCI的構(gòu)建速度。

構(gòu)建移動(dòng)CI平臺(tái)

我們通過構(gòu)建移動(dòng)CI平臺(tái)，來保證移動(dòng)研發(fā)在項(xiàng)目依賴極其復(fù)雜的情況下，也能互不影響完成業(yè)務(wù)研發(fā)集成；其次我們?cè)O(shè)計(jì)了合理的CI策略，來幫助移動(dòng)研發(fā)人員走出令人望而生畏的依賴關(guān)系管理的“泥潭”。

流程自動(dòng)化建設(shè)

在構(gòu)建移動(dòng)CI平臺(tái)的基礎(chǔ)上，我們對(duì)MCI流程進(jìn)行自動(dòng)化建設(shè)來解決研發(fā)流程瑣碎問題，從而解放移動(dòng)研發(fā)生產(chǎn)力。

提升構(gòu)建速度

在CI平臺(tái)保證集成正確性的情況下，我們通過依賴扁平化以及優(yōu)化集成方式等措施來提升MCI的構(gòu)建速度，進(jìn)一步提升研發(fā)效率。

靜態(tài)檢查體系

我們建立一套完整自研的靜態(tài)檢查體系，針對(duì)移動(dòng)項(xiàng)目的特點(diǎn)，MCI上線全方位的靜態(tài)檢查來促進(jìn)App質(zhì)量的提升。

日志監(jiān)控&分析

我們對(duì)MCI體系的完整流程進(jìn)行日志落地，方便問題的追溯與排查，同時(shí)通過數(shù)據(jù)分析來進(jìn)一步優(yōu)化MCI的流程以及監(jiān)控移動(dòng)App項(xiàng)目的健康狀況。

信息管理配置

最后，為了方便管理接入MCI的移動(dòng)項(xiàng)目，我們建設(shè)了統(tǒng)一的項(xiàng)目信息管理配置平臺(tái)。

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

四、構(gòu)建移動(dòng)CI平臺(tái)

4.1 搭建移動(dòng)CI平臺(tái)

我們對(duì)目前業(yè)內(nèi)流行的CI系統(tǒng)，如：Travis CI、 CircleCI、Jenkins、Gitlab CI調(diào)研后，針對(duì)移動(dòng)項(xiàng)目的特點(diǎn)，綜合考慮代碼安全性、可擴(kuò)展性及頁(yè)面可操作性，最終選擇基于Gitlab CI搭建移動(dòng)持續(xù)集成平臺(tái)，當(dāng)然我們也使用Jenkins做一些輔助性的工作。MCI體系的CI核心架構(gòu)如下圖所示：

名詞解釋：

• Gitlab CI：Gitlab CI是GitLab Continuous Integration（Gitlab持續(xù)集成）的簡(jiǎn)稱。
• Runner：Runner是Gitlab CI提供注冊(cè)CI服務(wù)器的接口。
• Pipeline：可以理解為流水線，包含CI不同階段的不同任務(wù)。
• Trigger：觸發(fā)器，Push代碼或者提交Merge Request等操作會(huì)觸發(fā)相應(yīng)的觸發(fā)器以進(jìn)入下一流程。

該架構(gòu)的優(yōu)勢(shì)是可擴(kuò)展性強(qiáng)、可定制、支持并發(fā)。首先CI服務(wù)器可以任意擴(kuò)展，除了專用的服務(wù)器可以作為CI服務(wù)器，普通個(gè)人PC機(jī)也可以作為CI服務(wù)器（缺點(diǎn)是性能比服務(wù)器差，任務(wù)執(zhí)行時(shí)間較長(zhǎng)）；其次每個(gè)集成任務(wù)的Pipeline是支持可定制的，托管在MCI的集成項(xiàng)目可以根據(jù)自身需求定制與之匹配的Pipeline；最后，每個(gè)集成項(xiàng)目的任務(wù)執(zhí)行是可并發(fā)的，因此各業(yè)務(wù)線間可以互不干擾的進(jìn)行組件代碼集成。

4.2 CI流程設(shè)計(jì)

一次完整的組件集成流程包含兩個(gè)階段：組件庫(kù)發(fā)版和向目標(biāo)App工程集成。如下圖所示：

第一階段，在日常功能開發(fā)完畢后，研發(fā)提PR到指定分支，在對(duì)代碼進(jìn)行Review、組件庫(kù)編譯及靜態(tài)檢查無誤后，自動(dòng)發(fā)版進(jìn)入組件池中。所有進(jìn)入組件池中的組件均可以在不同App項(xiàng)目中復(fù)用。

第二階段，研發(fā)根據(jù)需要將組件合入指定App工程。組件A本身的正確性已經(jīng)在第一階段的組件庫(kù)發(fā)版中驗(yàn)證，第二階段是檢查組件A的改變是否對(duì)目標(biāo)App中原有依賴它的其它組件造成影響。所以首先需要分析組件A被目標(biāo)App中哪些組件所依賴，目標(biāo)App工程按照各自的準(zhǔn)入標(biāo)準(zhǔn)，對(duì)合入的組件庫(kù)進(jìn)行編譯和靜態(tài)分析，待檢查無誤后，最終合入發(fā)布分支。

通過組件發(fā)版和集成兩階段的CI流程，組件將被正確集成到目標(biāo)項(xiàng)目中。而對(duì)于存在問題的組件則會(huì)阻擋在項(xiàng)目之外，因此不會(huì)影響其它業(yè)務(wù)的正常開發(fā)和發(fā)版集成，各業(yè)務(wù)研發(fā)流程獨(dú)立可控。

4.3 設(shè)計(jì)合理的CI策略

組件的發(fā)版和集成能否通過CI檢查，取決于組件當(dāng)前的依賴以及組件本身是否與目標(biāo)項(xiàng)目兼容。移動(dòng)研發(fā)需要對(duì)組件當(dāng)前依賴有足夠的了解才能順利完成發(fā)版集成，為了減小組件依賴管理的復(fù)雜度，我們?cè)O(shè)計(jì)了合理的發(fā)版集成策略來幫助移動(dòng)研發(fā)走出繁瑣的版本依賴管理的困境。

組件集成策略

每個(gè)組件都有自己的依賴項(xiàng)，不同組件可能會(huì)依賴同一個(gè)組件，組件向目標(biāo)項(xiàng)目集成過程中會(huì)面臨如下一些問題：

• 版本集成沖突：組件在集成過程中某個(gè)依賴項(xiàng)與目標(biāo)項(xiàng)目中現(xiàn)有依賴的版本號(hào)存在沖突。
• App測(cè)試包不穩(wěn)定：組件依賴項(xiàng)的版本發(fā)生變化導(dǎo)致在不同時(shí)刻打出不同依賴項(xiàng)的App測(cè)試包。

頻繁的版本集成沖突會(huì)導(dǎo)致業(yè)務(wù)協(xié)同開發(fā)集成效率低下，App測(cè)試包的不穩(wěn)定性會(huì)給研發(fā)追蹤問題帶來極大的困擾。問題的根源在于目標(biāo)項(xiàng)目使用每個(gè)組件的依賴項(xiàng)來進(jìn)行集成。因此我們通過在集成項(xiàng)目中顯示指定組件版本號(hào)以及禁止動(dòng)態(tài)依賴的方式，保證了App測(cè)試包的穩(wěn)定性和可靠性，同時(shí)也解決了組件版本集成沖突問題。

組件發(fā)版策略

組件向組件池發(fā)版也一樣會(huì)涉及依賴項(xiàng)的管理，簡(jiǎn)單粗暴的方法是指定所有依賴項(xiàng)的版本號(hào)，這樣做的好處是直觀明了，但研發(fā)需要對(duì)不同版本依賴項(xiàng)的功能有足夠的了解。正如組件集成策略中所述，集成項(xiàng)目中每個(gè)組件的版本都是顯示指定并且唯一確定的，組件中指定依賴項(xiàng)的版本號(hào)在集成項(xiàng)目中并不起作用。所以我們?cè)诮M件發(fā)版時(shí)采用自動(dòng)依賴組件池中最新版本的方式。這樣設(shè)計(jì)的好處在于：

• 避免移動(dòng)研發(fā)對(duì)版本依賴關(guān)系的處理。
• 給基礎(chǔ)組件的變更迭代提供了強(qiáng)有力的推動(dòng)機(jī)制。

當(dāng)基礎(chǔ)組件庫(kù)的接口和設(shè)計(jì)發(fā)生較大變化時(shí)，可以強(qiáng)有力的推動(dòng)業(yè)務(wù)層組件做相應(yīng)適配，保證了在高度解耦的項(xiàng)目架構(gòu)下保持高度的敏捷性。但這種能力不能濫用，需要根據(jù)業(yè)務(wù)迭代周期合理安排，并做好提前通知?jiǎng)訂T工作。

五、流程自動(dòng)化建設(shè)

研發(fā)流程瑣碎的主要原因是研發(fā)需要人工參與持續(xù)集成中每一步過程，一旦我們把移動(dòng)研發(fā)從持續(xù)集成過程中解放出來，自然就能提高研發(fā)生產(chǎn)力。我們通過項(xiàng)目集成發(fā)布流程自動(dòng)化以及優(yōu)化測(cè)試包分發(fā)來優(yōu)化MCI流程。

項(xiàng)目集成流程托管

研發(fā)流程中的組件發(fā)版、組件集成與App打包都是持續(xù)集成中的標(biāo)準(zhǔn)化流程，我們通過流程托管工具來完成這幾個(gè)步驟的自動(dòng)銜接，研發(fā)同學(xué)只需關(guān)注代碼開發(fā)與Bug修復(fù)。

流程托管工具實(shí)現(xiàn)方案如下：

• 自動(dòng)化流程執(zhí)行：通過托管隊(duì)列實(shí)現(xiàn)任務(wù)自動(dòng)化順序執(zhí)行，webhook實(shí)現(xiàn)流程狀態(tài)的監(jiān)聽。
• 關(guān)鍵節(jié)點(diǎn)通知：在關(guān)鍵性節(jié)點(diǎn)流程執(zhí)行成功后發(fā)送通知，讓研發(fā)對(duì)流程狀態(tài)了然于胸。
• 流程異常通知：一旦持續(xù)集成流程執(zhí)行異常，例如項(xiàng)目編譯失敗、靜態(tài)檢查沒通過等，第一時(shí)間通知研發(fā)及時(shí)處理。

打包發(fā)布流程托管

無論iOS還是Android，在發(fā)布App包到市場(chǎng)前都需要做一系列處理，例如iOS需要導(dǎo)出ipa包進(jìn)行備份，保存符號(hào)表來解析線上Crash，以及上傳ipa包到iTC（iTunes Connect）；而Android除了包備份，保存Mapping文件解析線上Crash外，還要發(fā)布App包到不同的渠道，整個(gè)打包發(fā)布流程更加復(fù)雜繁瑣。

在沒有MCI流程托管以前，每到App發(fā)布日，研發(fā)同學(xué)就如臨大敵守在打包機(jī)器前，披荊斬棘，過五關(guān)斬六將，直到所有App包被“運(yùn)送”到指定地點(diǎn)，搞得十分疲憊。如同項(xiàng)目集成流程托管一樣，我們把整個(gè)打包發(fā)布流程做了全流程托管，無人值守的自動(dòng)打包發(fā)布方式解放了研發(fā)同學(xué)，研發(fā)同學(xué)再也不用每次都披星戴月，早出晚歸，跪鍵盤了（捂臉）。

包分發(fā)流程建設(shè)

對(duì)于QA和研發(fā)而言，上面的場(chǎng)景是否似曾相識(shí)。Bug是QA與研發(fā)之間溝通的橋梁，但由于缺乏統(tǒng)一的包管理和分發(fā)，這種模糊的溝通導(dǎo)致難以快速定位和追溯發(fā)生問題的包。為了減少Q(mào)A和研發(fā)之間的無效溝通以及優(yōu)化包分發(fā)流程，我們亟需一個(gè)平臺(tái)來統(tǒng)一管理分發(fā)公司內(nèi)部的App包，于是MCI App應(yīng)運(yùn)而生。

MCI App提供如下功能：

• 查看下載安裝不同類型不同版本的App。
• 查看App包的基礎(chǔ)信息（打包者、打包耗時(shí)、包版本、代碼提交commit點(diǎn)等）。
• 查看App包當(dāng)前版本集成的所有組件庫(kù)信息。
• 查看App包體占用情況。
• 查詢App發(fā)版時(shí)間計(jì)劃。
• 分享安裝App包下載鏈接。

未來MCI App還會(huì)支持查詢項(xiàng)目集成狀態(tài)以及App發(fā)布提醒、問題反饋，整合移動(dòng)研發(fā)全流程。

六、提升構(gòu)建速度

移動(dòng)項(xiàng)目在構(gòu)建過程中最為耗時(shí)的兩個(gè)步驟分別為組件依賴計(jì)算和工程編譯。

組件依賴計(jì)算

組件依賴計(jì)算是根據(jù)項(xiàng)目中指定的集成組件計(jì)算出所有相關(guān)的依賴項(xiàng)以及依賴版本，當(dāng)項(xiàng)目中集成組件較多的時(shí)候，遞歸計(jì)算依賴項(xiàng)以及依賴版本是一件非常耗時(shí)的操作，特別是還要處理相關(guān)的依賴沖突。

工程編譯

工程編譯時(shí)間是跟項(xiàng)目工程的代碼量成正比的，集團(tuán)業(yè)務(wù)在快速發(fā)展，代碼量也在快速的膨脹。

為了提升項(xiàng)目構(gòu)建速度，我們通過依賴扁平化的方法來徹底去掉組件依賴計(jì)算耗時(shí)，以及通過優(yōu)化項(xiàng)目集成方式的手段來減少工程編譯時(shí)間。

依賴扁平化

依賴扁平化的核心思想是事先把依賴項(xiàng)以及依賴版本號(hào)進(jìn)行顯示指定，這樣通過固定依賴項(xiàng)以及依賴版本就徹底去掉了組件依賴計(jì)算的耗時(shí)，極大的提高了項(xiàng)目構(gòu)建速度。與此同時(shí)，依賴扁平化還額外帶來了下面的好處：

• 減輕研發(fā)依賴關(guān)系維護(hù)的負(fù)擔(dān)。
• App項(xiàng)目更加穩(wěn)定，不會(huì)因?yàn)橐蕾図?xiàng)的自動(dòng)升級(jí)出現(xiàn)問題。

優(yōu)化集成方式

通常組件代碼都是以源碼方式集成到目標(biāo)工程，這種集成方式的最大缺點(diǎn)是編譯速度慢，對(duì)于上百萬(wàn)行代碼的App，如果采用源碼集成的方式，工程編譯時(shí)間將超過40分鐘甚至更長(zhǎng)，這個(gè)時(shí)間，顯然會(huì)令人崩潰。

使用源碼集成

使用二進(jìn)制集成

實(shí)際上組件代碼還可以通過二進(jìn)制的方式集成到目標(biāo)工程：

相比源碼方式集成，組件的二進(jìn)制包都是預(yù)先編譯好的，在集成過程中只需要進(jìn)行鏈接無需編譯，因此二進(jìn)制集成的方式可以大幅提升項(xiàng)目編譯速度。

二進(jìn)制集成優(yōu)化

為了進(jìn)一步提高二進(jìn)制集成效率，我們還做了幾件小事：

（1）多線程下載

盡管二進(jìn)制集成的方式能減少工程編譯時(shí)間，但二進(jìn)制包還是得從遠(yuǎn)端下載到CI服務(wù)器上。我們修改了默認(rèn)單線程下載的策略，通過多線程下載二進(jìn)制包提升下載效率。

（2）二進(jìn)制包緩存

研發(fā)在MCI上觸發(fā)不同的集成任務(wù)，這些集成任務(wù)間除了升級(jí)的組件，其它使用的組件二進(jìn)制包大部分是相同的，因此我們?cè)贑I服務(wù)器上對(duì)組件二進(jìn)制包進(jìn)行緩存以便不同任務(wù)間進(jìn)行共享，進(jìn)一步提升項(xiàng)目構(gòu)建速度。

二進(jìn)制集成成果

我們?cè)贛CI中采用二進(jìn)制集成并且經(jīng)過一系列優(yōu)化后，iOS項(xiàng)目工程的編譯時(shí)間比原來減少60%，Android項(xiàng)目也比原來減少接近50%，極大地提升了項(xiàng)目構(gòu)建效率。

七、靜態(tài)檢查體系

除了完成日常需求開發(fā)，提高代碼質(zhì)量是每個(gè)研發(fā)的必修課。如果每一位移動(dòng)研發(fā)在平時(shí)開發(fā)中能嚴(yán)格遵守移動(dòng)編程規(guī)范與最佳實(shí)踐，那很多線上問題完全可以提前避免。事實(shí)上僅僅依靠研發(fā)自覺性，難以長(zhǎng)期有效的執(zhí)行，我們需要把這些移動(dòng)編程規(guī)范和最佳實(shí)踐切實(shí)落地成為靜態(tài)檢查強(qiáng)制執(zhí)行，才能有效的將問題扼殺在搖籃之中。

靜態(tài)檢查基礎(chǔ)設(shè)施

靜態(tài)檢查最簡(jiǎn)單的方式是文本匹配，這種方式檢查邏輯簡(jiǎn)單，但存在局限性。比如編寫的靜態(tài)檢查代碼維護(hù)困難，再者文本匹配能力有限對(duì)一些復(fù)雜邏輯的處理無能為力。現(xiàn)有針對(duì)Objective-C和Java的靜態(tài)分析工具也有不少，常見的有：OCLint、FindBugs、CheckStyle等等，但這些工具定制門檻較高。為了降低靜態(tài)檢查接入成本，我們自主研發(fā)了一個(gè)適應(yīng)MCI需求的靜態(tài)分析框架–Hades。

Hades的特點(diǎn)：

• 完全代碼語(yǔ)義理解
• 具備全局分析能力
• 支持增量分析
• 接入成本低

Hades的核心思想是對(duì)源碼生成的AST（Abstract Syntax Tree）進(jìn)行結(jié)構(gòu)化數(shù)據(jù)的語(yǔ)義表達(dá)，在此基礎(chǔ)上我們就可以建立一系列靜態(tài)分析工具和服務(wù)。作為一個(gè)靜態(tài)分析框架，Hades并不局限于Lint工具的制作，我們也希望通過這種結(jié)構(gòu)化的語(yǔ)義表達(dá)來對(duì)代碼有更深層次的理解。因此，我們可以借助文檔型數(shù)據(jù)庫(kù)（如：CouchDB、MongoDB等）建立項(xiàng)目代碼的語(yǔ)義模型數(shù)據(jù)庫(kù)，這樣我們能夠通過JS的Map-Reduce建立視圖從而快速檢索我們需要查找的內(nèi)容。關(guān)于Hades的技術(shù)實(shí)現(xiàn)原理我們將在后續(xù)的技術(shù)Blog中進(jìn)行詳細(xì)闡述，敬請(qǐng)期待。

MCI靜態(tài)檢查現(xiàn)狀

目前MCI已經(jīng)上線了覆蓋代碼基本規(guī)范、非空特性、多線程最佳實(shí)踐、資源合法性、啟動(dòng)流程管控、動(dòng)態(tài)行為管控等20多項(xiàng)靜態(tài)檢查，這些靜態(tài)檢查切實(shí)有效地促進(jìn)了App代碼質(zhì)量的提高。

八、日志監(jiān)控&分析

MCI作為大眾點(diǎn)評(píng)移動(dòng)端持續(xù)集成的重要平臺(tái)，穩(wěn)定高效是要達(dá)成的第一目標(biāo)，日志監(jiān)控是推動(dòng)MCI走向穩(wěn)定高效的重要手段。我們對(duì)MCI全流程的日志進(jìn)行落地，方便問題追溯與排查，以下是部分線上監(jiān)控項(xiàng)。

流程時(shí)間監(jiān)控分析

通過監(jiān)控分析MCI流程中每一步的執(zhí)行時(shí)間，我們可以進(jìn)行針對(duì)性的優(yōu)化以提高集成速度。

異常流程監(jiān)控分析

我們會(huì)對(duì)異常流程進(jìn)行監(jiān)控并且通知流程發(fā)起者，同時(shí)我們會(huì)對(duì)失敗次數(shù)較多的Job分析原因。一部分CI環(huán)境或者網(wǎng)絡(luò)問題MCI可以自動(dòng)解決，而其它由于代碼錯(cuò)誤引起的異常MCI會(huì)引導(dǎo)移動(dòng)研發(fā)進(jìn)行問題的排查與解決。

包體監(jiān)控分析

我們對(duì)包體總大小、可執(zhí)行文件以及圖片進(jìn)行全方面的監(jiān)控，包體變化的趨勢(shì)一目了然，對(duì)于包體的異常變化我們可以第一時(shí)間感知。

除此之外，我們還對(duì)MCI集成成功率、二進(jìn)制覆蓋率等方面做了監(jiān)控，做到對(duì)MCI全流程了然于胸，讓MCI穩(wěn)定高效的運(yùn)行。

九、信息管理配置

目前MCI平臺(tái)已經(jīng)接入公司多個(gè)移動(dòng)項(xiàng)目，為了接入MCI的項(xiàng)目進(jìn)行統(tǒng)一方便的信息管理，我們建設(shè)了MCI信息管理平臺(tái)——摩卡（Mocha）。Mocha平臺(tái)的功能包含項(xiàng)目信息管理、配置靜態(tài)檢查項(xiàng)以及組件發(fā)版集成查詢。

項(xiàng)目信息管理

Mocha平臺(tái)負(fù)責(zé)注冊(cè)接入MCI項(xiàng)目的基本信息，包含項(xiàng)目地址、項(xiàng)目負(fù)責(zé)人等，同時(shí)對(duì)各個(gè)項(xiàng)目的成員進(jìn)行權(quán)限管理。

配置靜態(tài)檢查項(xiàng)

MCI支持不同項(xiàng)目自定義不同的靜態(tài)檢查項(xiàng)，在Mocha平臺(tái)上可以完成項(xiàng)目所需靜態(tài)檢查項(xiàng)的定制，同時(shí)支持靜態(tài)檢查白名單的配置審核。

組件發(fā)版集成查詢

Mocha平臺(tái)支持組件歷史發(fā)版集成的記錄查詢，方便問題的排查與追溯。

作為移動(dòng)集成項(xiàng)目的可視化配置系統(tǒng)，Mocha平臺(tái)是MCI的一個(gè)重要補(bǔ)充。它使得移動(dòng)項(xiàng)目接入MCI變得簡(jiǎn)單快捷，未來Mocha平臺(tái)還會(huì)加入更多的配置項(xiàng)。

十、總結(jié)與展望

本文從大眾點(diǎn)評(píng)移動(dòng)項(xiàng)目業(yè)務(wù)復(fù)雜度出發(fā)，詳細(xì)介紹了構(gòu)建穩(wěn)定高效的移動(dòng)持續(xù)集成系統(tǒng)的思路與最佳實(shí)踐方案，解決項(xiàng)目依賴復(fù)雜所帶來的問題，通過依賴扁平化以及二進(jìn)制集成提升構(gòu)建速度。在此基礎(chǔ)上，通過自研的靜態(tài)檢查基礎(chǔ)設(shè)施Hades降低靜態(tài)檢查準(zhǔn)入的門檻，幫助提升App質(zhì)量；最后MCI提供的全流程托管能力能顯著提高移動(dòng)研發(fā)生產(chǎn)力。

目前MCI為iOS、Android原生代碼的項(xiàng)目集成已經(jīng)提供了相當(dāng)完善的支持。此外，MCI還支持Picasso項(xiàng)目的持續(xù)集成，Picasso是大眾點(diǎn)評(píng)自研的高性能跨平臺(tái)動(dòng)態(tài)化框架，專注于橫跨iOS、Android、Web、小程序四端的動(dòng)態(tài)化UI構(gòu)建。當(dāng)然移動(dòng)端原生項(xiàng)目的持續(xù)集成和動(dòng)態(tài)化項(xiàng)目的持續(xù)集成有共通也有很多不同之處。未來MCI將在移動(dòng)工程化領(lǐng)域進(jìn)一步探索，為移動(dòng)端業(yè)務(wù)蓬勃發(fā)展保駕護(hù)航。

作者簡(jiǎn)介

• 智聰，大眾點(diǎn)評(píng)iOS技術(shù)專家，專注于移動(dòng)工具鏈開發(fā)，對(duì)移動(dòng)持續(xù)集成、靜態(tài)分析平臺(tái)建設(shè)有深刻理解和豐富的實(shí)踐經(jīng)驗(yàn)。
• 邢軼，大眾點(diǎn)評(píng)Android技術(shù)專家，專注于移動(dòng)持續(xù)集成、靜態(tài)分析、靜態(tài)化等App基礎(chǔ)設(shè)施建設(shè)。

團(tuán)隊(duì)介紹

大眾點(diǎn)評(píng)移動(dòng)研發(fā)中心，Base上海，為美團(tuán)提供移動(dòng)端底層基礎(chǔ)設(shè)施服務(wù)，包含網(wǎng)絡(luò)通信、移動(dòng)監(jiān)控、推送觸達(dá)、動(dòng)態(tài)化引擎、移動(dòng)研發(fā)工具等。同時(shí)團(tuán)隊(duì)還承載流量分發(fā)、UGC、內(nèi)容生態(tài)、個(gè)人中心等業(yè)務(wù)研發(fā)工作，長(zhǎng)年虛位以待專注于移動(dòng)端研發(fā)的各路英雄豪杰。歡迎投遞簡(jiǎn)歷：dawei.xing#dianping.com。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的MCI：移动持续集成在大众点评的实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。