目前攜程大部分訂單已來(lái)自移動(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+。如果沒(méi)有一個(gè)有效的無(wú)線(xiàn)持續(xù)交付平臺(tái)，很難實(shí)現(xiàn)大版本的集成發(fā)布在 3 天內(nèi)完成。而對(duì)比市場(chǎng)上開(kāi)源的無(wú)線(xiàn)持續(xù)集成工具 Fastlane、TestFlight、Jenkins 都存在各種定制化需求的問(wèn)題。因此我們從零開(kāi)始，逐步打造適合攜程研發(fā)流程的無(wú)線(xiàn)交付平臺(tái)，系統(tǒng)化地解決研發(fā)支撐痛點(diǎn)。下面將從集成、測(cè)試、發(fā)布、運(yùn)營(yíng)四個(gè)子平臺(tái)來(lái)展開(kāi)，具體分享我們是如何一步步打造無(wú)線(xiàn)持續(xù)交付平臺(tái)的。

　　集成平臺(tái)

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

　　1.0 階段

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

　　在這個(gè)階段，App 的打包還完全依賴(lài)于源代碼進(jìn)行，由平臺(tái)生成打包參數(shù)（主要包含 App 運(yùn)行環(huán)境、與 iOS 簽名相關(guān)的參數(shù)以及代碼倉(cāng)庫(kù)相關(guān)的參數(shù)）提交給后臺(tái)的打包系統(tǒng)。它會(huì)根據(jù)倉(cāng)庫(kù)地址和 commit ID 從代碼倉(cāng)庫(kù)中拉取全量代碼，然后打包系統(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ǔ)上供用戶(hù)下載使用。

　　2.0 階段

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

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

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

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

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

　　針對(duì)以上問(wèn)題，我們對(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 之后不再輪詢(xún) 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 之間存在依賴(lài)關(guān)系。在這個(gè)情況下 App 的編譯和打包也可以按照 Bundle 的方式進(jìn)行組織。在開(kāi)發(fā)階段，開(kāi)發(fā)人員提交完代碼之后就能直接將自己負(fù)責(zé)的 Bundle 編譯成可執(zhí)行文件，測(cè)試可以自由選擇 Bundle 進(jìn)行打包。此時(shí)打包工作只需將多個(gè) Bundle 文件組裝在一起就行，極大地加快了打包速度。通過(guò)測(cè)試的 Bundle 會(huì)被發(fā)布到指定地點(diǎn)，在 App 集成階段只需把所有發(fā)布的 Bundle 組裝成最終 App 供大家測(cè)試即可。

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

相關(guān)電子資料下載

• 新一代 iPaaS 全域融合集成平臺(tái)，ROMA Connect HDC.Cloud 2023 內(nèi)容值得再讀！ 227
• 鏈接醫(yī)療數(shù)據(jù)！中軟國(guó)際智慧園區(qū)綜合集成平臺(tái)助力開(kāi)創(chuàng)智能醫(yī)院新時(shí)代 183
• AMD顯卡放棄掙扎？RX 8000被曝沒(méi)有旗艦 514
• 淺談智慧醫(yī)院的信息集成平臺(tái)建設(shè)與配電設(shè)計(jì)方案 148
• 華為云新一代 iPaaS 全域融合集成平臺(tái)全新升級(jí)！ 148
• 蘇州環(huán)球科技利用IBM混合云與AI軟件 成功構(gòu)建企業(yè)應(yīng)用集成平臺(tái)和業(yè)務(wù)流程管理 198
• 蘇州環(huán)球科技利用 IBM 混合云與 AI 軟件 成功構(gòu)建企業(yè)應(yīng)用集成平臺(tái)和業(yè)務(wù)流程 126
• Ansys Mechanical軟件：創(chuàng)建了一個(gè)使用有限元分析（FEA）進(jìn)?結(jié)構(gòu)分析的集成平臺(tái) 632
• 智慧醫(yī)院集成平臺(tái)的醫(yī)院信息化簡(jiǎn)單介紹 安科瑞 許敏 329
• 多功能集成平臺(tái)化會(huì)是建筑機(jī)器人的未來(lái)嗎？ 497