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

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

　　集成平臺

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

　　1.0 階段

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

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

　　2.0 階段

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

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

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

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

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

　　針對以上問題，我們對平臺進行了升級改造，主要為：

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

　　將工程進行拆分，按照 Bundle 的方式進行打包。

　　消息機制的改造：

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

　　圖 1 Bundle 打包工程拆分：

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

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