一、背景

目前，攜程小程序共有30+條業(yè)務(wù)線并行，上百個(gè)開發(fā)人員參與，常規(guī)發(fā)布兩周一次，這么大體量的小程序以及這么快的業(yè)務(wù)迭代速度，對(duì)我們的技術(shù)提出了更高的要求。

在攜程小程序的開發(fā)過(guò)程中，如何準(zhǔn)確快速地把小程序交付給測(cè)試人員是一個(gè)繁瑣的過(guò)程。按照以往的做法，開發(fā)人員將代碼提交至發(fā)布分支后，還需要自行到公司的MCD（攜程內(nèi)部發(fā)布平臺(tái)）進(jìn)行發(fā)布，并且存在十幾個(gè)業(yè)務(wù)線同時(shí)進(jìn)行，排隊(duì)打包的情況，打包完成后還要依賴PMO的發(fā)布才能獲得體驗(yàn)碼進(jìn)行測(cè)試。而理想的模式是，開發(fā)人員只需要進(jìn)行代碼的提交即可，無(wú)需關(guān)心項(xiàng)目編譯、打包、發(fā)布等流程。

跨團(tuán)隊(duì)協(xié)作，如何減少耦合，避免互相影響；數(shù)十個(gè)業(yè)務(wù)線共同維護(hù)一個(gè)小程序，而小程序必須作為整體發(fā)布，如何協(xié)調(diào)發(fā)布過(guò)程，讓其有條不紊的進(jìn)行將是我們討論的重點(diǎn)。本文將從倉(cāng)庫(kù)管理、持續(xù)集成、持續(xù)交付幾個(gè)方面進(jìn)行詳細(xì)介紹。

二、協(xié)同流程

攜程小程序以模塊化的思想，根據(jù)業(yè)務(wù)線對(duì)代碼進(jìn)行拆分隔離，采用多 BU （業(yè)務(wù)單元）的合作模式。為了避免多人協(xié)作時(shí)的版本切換和上線測(cè)試隔離等問(wèn)題，我們把一個(gè)完整的項(xiàng)目按照業(yè)務(wù)類別劃分為多個(gè)業(yè)務(wù)倉(cāng)庫(kù)，如基礎(chǔ)業(yè)務(wù)、酒店業(yè)務(wù)、機(jī)票業(yè)務(wù)、火車票業(yè)務(wù)等，相互之間不存在依賴關(guān)系；通過(guò)發(fā)布倉(cāng)庫(kù)將業(yè)務(wù)倉(cāng)庫(kù)的代碼進(jìn)行合并、打包、上傳，該倉(cāng)庫(kù)中的代碼為預(yù)發(fā)布版本，如圖1所示：

2.1 倉(cāng)庫(kù)管理

每個(gè)業(yè)務(wù)模塊都是一個(gè)獨(dú)立的Git倉(cāng)庫(kù)（即Bundle），互不影響，要想實(shí)現(xiàn)協(xié)同，所有的業(yè)務(wù)倉(cāng)庫(kù)必須要有統(tǒng)一的規(guī)范，倉(cāng)庫(kù)的規(guī)范有以下幾點(diǎn)：

• 命名規(guī)范：weixin-pages-業(yè)務(wù)名稱；
• 分支規(guī)范：master作為發(fā)布分支；
• 文件規(guī)范：只包含具體的業(yè)務(wù)代碼及app.json文件；
• 代碼提交規(guī)范：合并到發(fā)布分支上的代碼，要提交MR。

值得注意的是，在實(shí)現(xiàn)模塊化的過(guò)程中，業(yè)務(wù)模塊已經(jīng)隔離，每個(gè)業(yè)務(wù)倉(cāng)庫(kù)都不能獨(dú)立運(yùn)行。為了協(xié)調(diào)各個(gè)倉(cāng)庫(kù)的路由配置，我們規(guī)定在每個(gè)模塊的根目錄下，添加各自的 app.json 配置，用于配置業(yè)務(wù)模塊的路由，然后在工具打包時(shí)，將各模塊的路由進(jìn)行合并 Merge，對(duì)應(yīng)關(guān)系如下圖：

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

執(zhí)行簡(jiǎn)單的命令minitTools —init即可拉取各個(gè)業(yè)務(wù)倉(cāng)庫(kù)中的代碼，并將其合并成一個(gè)完整的小程序在微信IDE中進(jìn)行開發(fā)。

除了倉(cāng)庫(kù)規(guī)范，還需要對(duì)每個(gè)業(yè)務(wù)倉(cāng)庫(kù)的webhooks進(jìn)行配置，用于跨倉(cāng)庫(kù)提交代碼的同時(shí)觸發(fā)發(fā)布倉(cāng)庫(kù)（weixin-auto.git）的pipeline。

2.2 持續(xù)集成

為了降低開發(fā)成本，減少人工操作，基于微信小程序官方提供的miniprogram-ci工具，我們構(gòu)建了一套自動(dòng)化上傳測(cè)試流程。通過(guò)在業(yè)務(wù)倉(cāng)庫(kù)配置webhooks，當(dāng)業(yè)務(wù)倉(cāng)庫(kù)的發(fā)布分支（master）發(fā)生push事件時(shí)將觸發(fā)發(fā)布倉(cāng)庫(kù)（weixin-auto.git）的pipeline，執(zhí)行我們?cè)?.gitlab-ci.yml文件中的設(shè)置的腳本，主要內(nèi)容如下：

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

1）獲取服務(wù)端配置信息，主要包括releaseCommitHash、Size、RC（Release Candidate）數(shù)據(jù)：

• releaseCommitHash：用于版本控制，表示業(yè)務(wù)倉(cāng)庫(kù)在生產(chǎn)上使用的版本（commitHash）；
• Size：用于Size控制，對(duì)各個(gè)業(yè)務(wù)線設(shè)置了可用的最大Size值；
• RC：用于控制該業(yè)務(wù)倉(cāng)庫(kù)的代碼是否會(huì)自動(dòng)合并至發(fā)布倉(cāng)庫(kù)中。

2）通過(guò)releaseCommitHash拉取各個(gè)業(yè)務(wù)倉(cāng)庫(kù)最新的代碼并進(jìn)行合并，組成完整的小程序代碼；

3）通過(guò)ESLint進(jìn)行代碼合法性檢查，最大程度地避免基本語(yǔ)法錯(cuò)誤；

4）通過(guò)微信官方提供的miniprogram-ci工具，進(jìn)行自動(dòng)化編譯，刪除無(wú)用代碼減小體積；

5）Size檢查：通過(guò)微信官方提供的miniprogram-ci的preview方法獲取所有分包的大小以及測(cè)試二維碼，通過(guò)計(jì)算查看當(dāng)前業(yè)務(wù)倉(cāng)庫(kù)的代碼提交是否會(huì)導(dǎo)致在Size超限，超限將導(dǎo)致發(fā)布失?。?/p>

6）RC發(fā)布權(quán)限檢查：服務(wù)端返回當(dāng)前業(yè)務(wù)倉(cāng)庫(kù)的RC值（true/false）決定了我們是否要將其最新的代碼合并至發(fā)布倉(cāng)庫(kù)的master分支，并且是否將最新的代碼壓縮成zip包，上傳至發(fā)布倉(cāng)庫(kù)的release分支作為預(yù)發(fā)布版本。最終發(fā)布倉(cāng)庫(kù)（weixin-auto.git）master、release分支的目錄結(jié)構(gòu)如下圖所示：

7）數(shù)據(jù)更新：如果RC為true并且代碼成功上傳之后，我們將同步更新該業(yè)務(wù)倉(cāng)庫(kù)的releaseCommitHash、分包Size等信息至服務(wù)端中，以便別的業(yè)務(wù)倉(cāng)庫(kù)可以拉到該倉(cāng)庫(kù)最新的代碼；

8）構(gòu)建結(jié)果通知：無(wú)論成功與否，構(gòu)建的結(jié)果都將發(fā)送至相關(guān)的群組以及觸發(fā)該pipeline的人員，如果失敗，將返回詳細(xì)的錯(cuò)誤信息進(jìn)行排障，成功將返回測(cè)試二維碼，如下圖所示：

圖2-5 構(gòu)建結(jié)果通知

上述步驟任何一步失敗都將導(dǎo)致pipeline失敗，通過(guò)上述流程，確保提交到發(fā)布倉(cāng)庫(kù)的代碼均為正確無(wú)誤的代碼。

2.3 持續(xù)交付

目前，攜程微信小程序的發(fā)布已經(jīng)統(tǒng)一接入公司的MCD發(fā)布平臺(tái)，將事先寫好的python腳本在MCD平臺(tái)上進(jìn)行配置，臨近發(fā)布節(jié)點(diǎn)，PMO只需到MCD平臺(tái)上進(jìn)行集成發(fā)布。此時(shí)MCD將自動(dòng)運(yùn)行我們預(yù)設(shè)的腳本，該腳本將拉取發(fā)布倉(cāng)庫(kù)release分支上的zip包，將其進(jìn)行整理，生成體驗(yàn)版二維碼，由PMO發(fā)給相關(guān)人員進(jìn)行集成測(cè)試。

測(cè)試通過(guò)后，再有PMO將代碼手動(dòng)提交至微信后臺(tái)進(jìn)行審核，至此，一次完整的常規(guī)發(fā)布流程已經(jīng)完成。

三、總結(jié)

綜上所述，通過(guò)倉(cāng)庫(kù)管理將各個(gè)業(yè)務(wù)線分割成獨(dú)立的git倉(cāng)庫(kù)，保證業(yè)務(wù)的獨(dú)立開發(fā)、互不影響；通過(guò)pipeline自動(dòng)化持續(xù)集成方案并結(jié)合公司的MCD發(fā)布平臺(tái)進(jìn)行持續(xù)交付，大大簡(jiǎn)化了一線開發(fā)人員的開發(fā)成本，只需提交代碼即可，打包、測(cè)試、上傳、預(yù)覽、通知等操作均由發(fā)布倉(cāng)庫(kù)的pipeline自動(dòng)化完成，避免了人工操作的不穩(wěn)定性與繁瑣，確保了業(yè)務(wù)的敏捷開發(fā)以及協(xié)同合作效率。

本文僅介紹了常規(guī)業(yè)務(wù)線協(xié)同開發(fā)的流程，其實(shí)攜程微信小程序早已引入了Taro這一概念，并且針對(duì)使用Taro技術(shù)棧的業(yè)務(wù)線設(shè)計(jì)了一套獨(dú)有的打包方式，目前在微信小程序中運(yùn)行良好，我們正在穩(wěn)步向其他各類小程序（百度、頭條、支付寶等）中推廣。

團(tuán)隊(duì)招聘信息

我們是平臺(tái)研發(fā)中心，一個(gè)為攜程快速發(fā)展提供各類基礎(chǔ)產(chǎn)品和服務(wù)的平臺(tái)，我們以技術(shù)驅(qū)動(dòng)提升客戶體驗(yàn)，提升跨團(tuán)隊(duì)協(xié)作效率。

我們擁有優(yōu)秀而強(qiáng)大的團(tuán)隊(duì)，引導(dǎo)你學(xué)習(xí)業(yè)內(nèi)領(lǐng)先的開發(fā)技術(shù)，與技術(shù)高手交流對(duì)話，學(xué)習(xí)切磋。在億級(jí)用戶嚴(yán)苛的品質(zhì)要求中，激發(fā)你腦中不斷涌現(xiàn)的創(chuàng)新思維，帶領(lǐng)你體驗(yàn)飛速成長(zhǎng)的驚喜快樂(lè)，并在各種機(jī)遇與挑戰(zhàn)中發(fā)展自我，成就自身。

目前我們前端、后臺(tái)、算法、測(cè)試等技術(shù)崗位均有職位。簡(jiǎn)歷投遞： [email protected] ，郵件標(biāo)題：【姓名】-【攜程平臺(tái)研發(fā)中心】-【投遞職位】

【作者簡(jiǎn)介】

攜程前端框架團(tuán)隊(duì)，為攜程集團(tuán)各業(yè)務(wù)線在PC、H5、小程序等各階段提供優(yōu)秀的Web解決方案。產(chǎn)品涉及各類前端/Node端應(yīng)用框架、研發(fā)工作臺(tái)、前端中臺(tái)化、靜態(tài)資源發(fā)布系統(tǒng)等。當(dāng)前主要專注方向包括：新一代研發(fā)模式探索，Rust構(gòu)建工具鏈路升級(jí)、Serverless應(yīng)用框架開發(fā)、在線文檔系統(tǒng)開發(fā)、低代碼平臺(tái)搭建、適老化與無(wú)障礙探索等。