一、背景

目前，攜程小程序共有30+條業務線并行，上(shàng)百個(gè)開發人(rén)員參與，常規發布兩周一次，這(zhè)麽大(dà)體量的(de)小程序以(yǐ)及這(zhè)麽快的(de)業務叠代速度，對我們的(de)技術提出(chū)了(le／liǎo)更高的(de)要(yào / yāo)求。

在(zài)攜程小程序的(de)開發過程中，如何準确快速地(dì / de)把小程序交付給測試人(rén)員是(shì)一個(gè)繁瑣的(de)過程。按照以(yǐ)往的(de)做法，開發人(rén)員将代碼提交至發布分支後，還需要(yào / yāo)自行到(dào)公司的(de)MCD（攜程内部發布平台）進行發布，并且存在(zài)十幾個(gè)業務線同時(shí)進行，排隊打包的(de)情況，打包完成後還要(yào / yāo)依賴PMO的(de)發布才能獲得體驗碼進行測試。而(ér)理想的(de)模式是(shì)，開發人(rén)員隻需要(yào / yāo)進行代碼的(de)提交即可，無需關心項目編譯、打包、發布等流程。

跨團隊協作，如何減少耦合，避免互相影響；數十個(gè)業務線共同維護一個(gè)小程序，而(ér)小程序必須作爲(wéi / wèi)整體發布，如何協調發布過程，讓其有條不(bù)紊的(de)進行将是(shì)我們讨論的(de)重點。本文将從倉庫管理、持續集成、持續交付幾個(gè)方面進行詳細介紹。

二、協同流程

攜程小程序以(yǐ)模塊化的(de)思想，根據業務線對代碼進行拆分隔離，采用多 BU （業務單元）的(de)合作模式。爲(wéi / wèi)了(le／liǎo)避免多人(rén)協作時(shí)的(de)版本切換和(hé / huò)上(shàng)線測試隔離等問題，我們把一個(gè)完整的(de)項目按照業務類别劃分爲(wéi / wèi)多個(gè)業務倉庫，如基礎業務、酒店業務、機票業務、火車票業務等，相互之(zhī)間不(bù)存在(zài)依賴關系；通過發布倉庫将業務倉庫的(de)代碼進行合并、打包、上(shàng)傳，該倉庫中的(de)代碼爲(wéi / wèi)預發布版本，如圖1所示：

2.1 倉庫管理

每個(gè)業務模塊都是(shì)一個(gè)獨立的(de)Git倉庫（即Bundle），互不(bù)影響，要(yào / yāo)想實現協同，所有的(de)業務倉庫必須要(yào / yāo)有統一的(de)規範，倉庫的(de)規範有以(yǐ)下幾點：

• 命名規範：weixin-pages-業務名稱；
• 分支規範：master作爲(wéi / wèi)發布分支；
• 文件規範：隻包含具體的(de)業務代碼及app.json文件；
• 代碼提交規範：合并到(dào)發布分支上(shàng)的(de)代碼，要(yào / yāo)提交MR。

值得注意的(de)是(shì)，在(zài)實現模塊化的(de)過程中，業務模塊已經隔離，每個(gè)業務倉庫都不(bù)能獨立運行。爲(wéi / wèi)了(le／liǎo)協調各個(gè)倉庫的(de)路由配置，我們規定在(zài)每個(gè)模塊的(de)根目錄下，添加各自的(de) app.json 配置，用于(yú)配置業務模塊的(de)路由，然後在(zài)工具打包時(shí)，将各模塊的(de)路由進行合并 Merge，對應關系如下圖：

而(ér)在(zài)開發階段需要(yào / yāo)用到(dào)我們提供的(de)腳手架工具miniTools來(lái)完成項目的(de)初始化、代碼更新、遠端Bundle打包等操作，常用命令如下所示：

執行簡單的(de)命令minitTools —init即可拉取各個(gè)業務倉庫中的(de)代碼，并将其合并成一個(gè)完整的(de)小程序在(zài)微信IDE中進行開發。

除了(le／liǎo)倉庫規範，還需要(yào / yāo)對每個(gè)業務倉庫的(de)webhooks進行配置，用于(yú)跨倉庫提交代碼的(de)同時(shí)觸發發布倉庫（weixin-auto.git）的(de)pipeline。

2.2 持續集成

爲(wéi / wèi)了(le／liǎo)降低開發成本，減少人(rén)工操作，基于(yú)微信小程序官方提供的(de)miniprogram-ci工具，我們構建了(le／liǎo)一套自動化上(shàng)傳測試流程。通過在(zài)業務倉庫配置webhooks，當業務倉庫的(de)發布分支（master）發生push事件時(shí)将觸發發布倉庫（weixin-auto.git）的(de)pipeline，執行我們在(zài) .gitlab-ci.yml文件中的(de)設置的(de)腳本，主要(yào / yāo)内容如下：

從上(shàng)圖可以(yǐ)看出(chū)，我們主要(yào / yāo)依賴git提供的(de)git submodule命令以(yǐ)及腳手架工具miniTools。通過git submodule update --remote将第三方庫（各個(gè)業務倉庫）中最新提交到(dào)指定分支的(de)代碼合并到(dào)當前倉庫（發布倉庫）的(de)指定位置中。然後，通過腳手架工具miniTools執行預定義的(de)腳本文件，具體流程如下：

1）獲取服務端配置信息，主要(yào / yāo)包括releaseCommitHash、Size、RC（Release Candidate）數據：

• releaseCommitHash：用于(yú)版本控制，表示業務倉庫在(zài)生産上(shàng)使用的(de)版本（commitHash）；
• Size：用于(yú)Size控制，對各個(gè)業務線設置了(le／liǎo)可用的(de)最大(dà)Size值；
• RC：用于(yú)控制該業務倉庫的(de)代碼是(shì)否會自動合并至發布倉庫中。

2）通過releaseCommitHash拉取各個(gè)業務倉庫最新的(de)代碼并進行合并，組成完整的(de)小程序代碼；

3）通過ESLint進行代碼合法性檢查，最大(dà)程度地(dì / de)避免基本語法錯誤；

4）通過微信官方提供的(de)miniprogram-ci工具，進行自動化編譯，删除無用代碼減小體積；

5）Size檢查：通過微信官方提供的(de)miniprogram-ci的(de)preview方法獲取所有分包的(de)大(dà)小以(yǐ)及測試二維碼，通過計算查看當前業務倉庫的(de)代碼提交是(shì)否會導緻在(zài)Size超限，超限将導緻發布失敗；

6）RC發布權限檢查：服務端返回當前業務倉庫的(de)RC值（true/false）決定了(le／liǎo)我們是(shì)否要(yào / yāo)将其最新的(de)代碼合并至發布倉庫的(de)master分支，并且是(shì)否将最新的(de)代碼壓縮成zip包，上(shàng)傳至發布倉庫的(de)release分支作爲(wéi / wèi)預發布版本。最終發布倉庫（weixin-auto.git）master、release分支的(de)目錄結構如下圖所示：

7）數據更新：如果RC爲(wéi / wèi)true并且代碼成功上(shàng)傳之(zhī)後，我們将同步更新該業務倉庫的(de)releaseCommitHash、分包Size等信息至服務端中，以(yǐ)便别的(de)業務倉庫可以(yǐ)拉到(dào)該倉庫最新的(de)代碼；

8）構建結果通知：無論成功與否，構建的(de)結果都将發送至相關的(de)群組以(yǐ)及觸發該pipeline的(de)人(rén)員，如果失敗，将返回詳細的(de)錯誤信息進行排障，成功将返回測試二維碼，如下圖所示：

圖2-5 構建結果通知

上(shàng)述步驟任何一步失敗都将導緻pipeline失敗，通過上(shàng)述流程，确保提交到(dào)發布倉庫的(de)代碼均爲(wéi / wèi)正确無誤的(de)代碼。

2.3 持續交付

目前，攜程微信小程序的(de)發布已經統一接入公司的(de)MCD發布平台，将事先寫好的(de)python腳本在(zài)MCD平台上(shàng)進行配置，臨近發布節點，PMO隻需到(dào)MCD平台上(shàng)進行集成發布。此時(shí)MCD将自動運行我們預設的(de)腳本，該腳本将拉取發布倉庫release分支上(shàng)的(de)zip包，将其進行整理，生成體驗版二維碼，由PMO發給相關人(rén)員進行集成測試。

測試通過後，再有PMO将代碼手動提交至微信後台進行審核，至此，一次完整的(de)常規發布流程已經完成。

三、總結

綜上(shàng)所述，通過倉庫管理将各個(gè)業務線分割成獨立的(de)git倉庫，保證業務的(de)獨立開發、互不(bù)影響；通過pipeline自動化持續集成方案并結合公司的(de)MCD發布平台進行持續交付，大(dà)大(dà)簡化了(le／liǎo)一線開發人(rén)員的(de)開發成本，隻需提交代碼即可，打包、測試、上(shàng)傳、預覽、通知等操作均由發布倉庫的(de)pipeline自動化完成，避免了(le／liǎo)人(rén)工操作的(de)不(bù)穩定性與繁瑣，确保了(le／liǎo)業務的(de)敏捷開發以(yǐ)及協同合作效率。

本文僅介紹了(le／liǎo)常規業務線協同開發的(de)流程，其實攜程微信小程序早已引入了(le／liǎo)Taro這(zhè)一概念，并且針對使用Taro技術棧的(de)業務線設計了(le／liǎo)一套獨有的(de)打包方式，目前在(zài)微信小程序中運行良好，我們正在(zài)穩步向其他(tā)各類小程序（百度、頭條、支付寶等）中推廣。

團隊招聘信息

我們是(shì)平台研發中心，一個(gè)爲(wéi / wèi)攜程快速發展提供各類基礎産品和(hé / huò)服務的(de)平台，我們以(yǐ)技術驅動提升客戶體驗，提升跨團隊協作效率。

我們擁有優秀而(ér)強大(dà)的(de)團隊，引導你學習業内領先的(de)開發技術，與技術高手交流對話，學習切磋。在(zài)億級用戶嚴苛的(de)品質要(yào / yāo)求中，激發你腦中不(bù)斷湧現的(de)創新思維，帶領你體驗飛速成長的(de)驚喜快樂，并在(zài)各種機遇與挑戰中發展自我，成就(jiù)自身。

目前我們前端、後台、算法、測試等技術崗位均有職位。簡曆投遞： tech@trip.com ，郵件标題：【姓名】-【攜程平台研發中心】-【投遞職位】

【作者簡介】

攜程前端框架團隊，爲(wéi / wèi)攜程集團各業務線在(zài)PC、H5、小程序等各階段提供優秀的(de)Web解決方案。産品涉及各類前端/Node端應用框架、研發工作台、前端中台化、靜态資源發布系統等。當前主要(yào / yāo)專注方向包括：新一代研發模式探索，Rust構建工具鏈路升級、Serverless應用框架開發、在(zài)線文檔系統開發、低代碼平台搭建、适老化與無障礙探索等。