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

　　集成平臺

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

　　1.0 階段

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

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

　　2.0 階段

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

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

　　編譯容易失敗，任何一個 Check-in 導致的編譯失敗，就會致使系統不能正常出包。

　　系統之間采用輪詢模式，Job 任務擴展性差。

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

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

　　引入消息機制，提高系統吞吐量；

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

　　消息機制的改造：

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

　　圖 1 Bundle 打包工程拆分：

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

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

相關電子資料下載

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