實(shí)例分析無線持續(xù)交付平臺(tái) MCD 的實(shí)踐應(yīng)用

　　目前攜程大部分訂單已來自移動(dòng)端，App 幾乎承載了整個(gè)集團(tuán)的所有業(yè)務(wù)形態(tài)。在內(nèi)部研發(fā)中，攜程的 App 已經(jīng)發(fā)展成為擁有 90+ Native Bundle、100+ Hybrid Bundle、30+ React Native Bundle，幾百名研發(fā)人員，每個(gè)版本（1 個(gè)月）交付 4000+個(gè) App 包，Hybrid/React Native/HotFix/Bundle 發(fā)布次數(shù) 500+。如果沒有一個(gè)有效的無線持續(xù)交付平臺(tái)，很難實(shí)現(xiàn)大版本的集成發(fā)布在 3 天內(nèi)完成。而對(duì)比市場(chǎng)上開源的無線持續(xù)集成工具 Fastlane、TestFlight、Jenkins 都存在各種定制化需求的問題。因此我們從零開始，逐步打造適合攜程研發(fā)流程的無線交付平臺(tái)，系統(tǒng)化地解決研發(fā)支撐痛點(diǎn)。下面將從集成、測(cè)試、發(fā)布、運(yùn)營四個(gè)子平臺(tái)來展開，具體分享我們是如何一步步打造無線持續(xù)交付平臺(tái)的。

　　集成平臺(tái)

　　從最初到現(xiàn)在，攜程無線持續(xù)交付模型經(jīng)歷了從 1.0 到 2.0 的迭代演進(jìn)。在 1.0 之前，App 集成和發(fā)布還主要依靠人工操作 Jenkins，需要由特定的打包人員負(fù)責(zé)打包，再將包通過 IM/郵件等方式傳遞給其他測(cè)試人員，測(cè)試結(jié)果需要專人手工回收，以把控 App 質(zhì)量。此時(shí)最大的問題就是 App 管理混亂，人工介入過多，每次發(fā)布都需要花費(fèi)很長的時(shí)間。

　　1.0 階段

　　在 1.0 階段，我們引入 MCD（Mobile Continues Delivery）平臺(tái)思路，將打包人員的工作交給平臺(tái)來完成，提高了發(fā)布工作效率。這時(shí)不需要專職人員負(fù)責(zé)出包，平臺(tái)會(huì)定時(shí)自動(dòng)打包，測(cè)試人員可以到平臺(tái)上自由取包（通過下載鏈接或掃描二維碼的方式）進(jìn)行測(cè)試。與此同時(shí)，測(cè)試人員也可以在平臺(tái)上進(jìn)行單獨(dú)的打包和測(cè)試。測(cè)試結(jié)果會(huì)統(tǒng)一反饋到平臺(tái)上來，協(xié)調(diào)人員在平臺(tái)根據(jù)各家的反饋結(jié)果決定需要重新出包還是繼續(xù)下一步發(fā)布操作。

　　在這個(gè)階段，App 的打包還完全依賴于源代碼進(jìn)行，由平臺(tái)生成打包參數(shù)（主要包含 App 運(yùn)行環(huán)境、與 iOS 簽名相關(guān)的參數(shù)以及代碼倉庫相關(guān)的參數(shù)）提交給后臺(tái)的打包系統(tǒng)。它會(huì)根據(jù)倉庫地址和 commit ID 從代碼倉庫中拉取全量代碼，然后打包系統(tǒng)再調(diào)用代碼中預(yù)先準(zhǔn)備好的 Build 腳本構(gòu)建 App 產(chǎn)物，構(gòu)建完成后將結(jié)果保存至臨時(shí)的文件服務(wù)中，最后由平臺(tái)的回收進(jìn)程將構(gòu)建結(jié)果回收并處理之后放在云存儲(chǔ)上供用戶下載使用。

　　2.0 階段

　　1.0 階段雖然已經(jīng)基本實(shí)現(xiàn)了集成打包的自動(dòng)化，但是還存在以下幾點(diǎn)不足：

　　源碼打包方式效率低下，每次都要從代碼倉庫中下載全量代碼，再通過源代碼生成 App 產(chǎn)物。這樣做使得每次 Build 時(shí)間都很長，而打包次數(shù)的增加會(huì)導(dǎo)致某些打包任務(wù)積壓，系統(tǒng)不能及時(shí)出包。

　　編譯容易失敗，任何一個(gè) Check-in 導(dǎo)致的編譯失敗，就會(huì)致使系統(tǒng)不能正常出包。

　　系統(tǒng)之間采用輪詢模式，Job 任務(wù)擴(kuò)展性差。

　　MCD 系統(tǒng)發(fā)起 Build 請(qǐng)求之后會(huì)有另一個(gè)定時(shí)的 Job 任務(wù)去輪詢 Build Server 查看 Build 結(jié)果。在初期階段還能滿足業(yè)務(wù)需求，但是后來由于打包數(shù)量的增加以及打包頻率的提高，系統(tǒng)的處理效率變得越來越低。一方面打包資源不夠（Android 打包使用 Linux 虛擬機(jī)，iOS 打包使用 Mac），另一方面輪詢 Job 的處理效率達(dá)到了瓶頸。打包機(jī)器采用 Jenkins 方式進(jìn)行管理，因此很容易進(jìn)行橫向擴(kuò)展，但是 Job 卻很難擴(kuò)容。

　　針對(duì)以上問題，我們對(duì)平臺(tái)進(jìn)行了升級(jí)改造，主要為：

　　引入消息機(jī)制，提高系統(tǒng)吞吐量；

　　將工程進(jìn)行拆分，按照 Bundle 的方式進(jìn)行打包。

　　消息機(jī)制的改造：

　　首先基本打包架構(gòu)和流程保持不變，在 MCD 系統(tǒng)和 Build Server 之間增加消息系統(tǒng)，MCD 發(fā)起 Build 之后不再輪詢 Build Server，而是消費(fèi)由 Build Server 產(chǎn)生的 Build 完成消息，如圖 1 所示。使用這樣的生產(chǎn)消費(fèi)模型 MCD 可以輕易地進(jìn)行水平擴(kuò)展，系統(tǒng)執(zhí)行效率得到極大改善。

　　圖 1 Bundle 打包工程拆分：

　　App 工程拆分成多個(gè)不同的 Bundle 模塊，Bundle 之間存在依賴關(guān)系。在這個(gè)情況下 App 的編譯和打包也可以按照 Bundle 的方式進(jìn)行組織。在開發(fā)階段，開發(fā)人員提交完代碼之后就能直接將自己負(fù)責(zé)的 Bundle 編譯成可執(zhí)行文件，測(cè)試可以自由選擇 Bundle 進(jìn)行打包。此時(shí)打包工作只需將多個(gè) Bundle 文件組裝在一起就行，極大地加快了打包速度。通過測(cè)試的 Bundle 會(huì)被發(fā)布到指定地點(diǎn)，在 App 集成階段只需把所有發(fā)布的 Bundle 組裝成最終 App 供大家測(cè)試即可。

　　在開發(fā)自測(cè)階段，開發(fā)人員提交完代碼后在 MCD 平臺(tái)上 Build 出所開發(fā)的 Bundle（標(biāo)記為 L，表示 Latest）。相關(guān)測(cè)試人員（或開發(fā)人員自己）可以打測(cè)試包，測(cè)試包會(huì)使用所有 Bunde 的 L 版本進(jìn)行構(gòu)建。構(gòu)建完成之后獲取測(cè)試包進(jìn)行功能測(cè)試，測(cè)試通過后就可以將該 Bundle 進(jìn)行發(fā)布操作，即標(biāo)記為 RC 版本（表示 Release Candidate）。