干货 | 30+条业务线，携程微信小程序如何协同开发

作者简介

携程前端框架团队，为携程集团各业务线在PC、H5、小程序等各阶段提供优秀的Web解决方案。产品涉及各类前端/Node端应用框架、研发工作台、前端中台化、静态资源发布系统等。当前主要专注方向包括：新一代研发模式探索，Rust构建工具链路升级、Serverless应用框架开发、在线文档系统开发、低代码平台搭建、适老化与无障碍探索等。

一、背景

目前，携程小程序共有30+条业务线并行，上百个开发人员参与，常规发布两周一次，这么大体量的小程序以及这么快的业务迭代速度，对我们的技术提出了更高的要求。

在携程小程序的开发过程中，如何准确快速地把小程序交付给测试人员是一个繁琐的过程。按照以往的做法，开发人员将代码提交至发布分支后，还需要自行到公司的MCD（携程内部发布平台）进行发布，并且存在十几个业务线同时进行，排队打包的情况，打包完成后还要依赖PMO的发布才能获得体验码进行测试。而理想的模式是，开发人员只需要进行代码的提交即可，无需关心项目编译、打包、发布等流程。

跨团队协作，如何减少耦合，避免互相影响；数十个业务线共同维护一个小程序，而小程序必须作为整体发布，如何协调发布过程，让其有条不紊的进行将是我们讨论的重点。本文将从仓库管理、持续集成、持续交付几个方面进行详细介绍。

二、协同流程

携程小程序以模块化的思想，根据业务线对代码进行拆分隔离，采用多 BU （业务单元）的合作模式。为了避免多人协作时的版本切换和上线测试隔离等问题，我们把一个完整的项目按照业务类别划分为多个业务仓库，如基础业务、酒店业务、机票业务、火车票业务等，相互之间不存在依赖关系；通过发布仓库将业务仓库的代码进行合并、打包、上传，该仓库中的代码为预发布版本，如图1所示：

图1 协同架构图

2.1 仓库管理

每个业务模块都是一个独立的Git仓库（即Bundle），互不影响，要想实现协同，所有的业务仓库必须要有统一的规范，仓库的规范有以下几点：

• 命名规范：weixin-pages-业务名称；
• 分支规范：master作为发布分支；
• 文件规范：只包含具体的业务代码及app.json文件；
• 代码提交规范：合并到发布分支上的代码，要提交MR。

值得注意的是，在实现模块化的过程中，业务模块已经隔离，每个业务仓库都不能独立运行。为了协调各个仓库的路由配置，我们规定在每个模块的根目录下，添加各自的 app.json 配置，用于配置业务模块的路由，然后在工具打包时，将各模块的路由进行合并 Merge，对应关系如下图：

图2-1 业务仓库与完整小程序目录对照图

而在开发阶段需要用到我们提供的脚手架工具miniTools来完成项目的初始化、代码更新、远端Bundle打包等操作，常用命令如下所示：

执行简单的命令minitTools —init即可拉取各个业务仓库中的代码，并将其合并成一个完整的小程序在微信IDE中进行开发。

除了仓库规范，还需要对每个业务仓库的webhooks进行配置，用于跨仓库提交代码的同时触发发布仓库（weixin-auto.git）的pipeline。

2.2 持续集成

为了降低开发成本，减少人工操作，基于微信小程序官方提供的miniprogram-ci工具，我们构建了一套自动化上传测试流程。通过在业务仓库配置webhooks，当业务仓库的发布分支（master）发生push事件时将触发发布仓库（weixin-auto.git）的pipeline，执行我们在 .gitlab-ci.yml文件中的设置的脚本，主要内容如下：

图2-2 gitlab-ci.yml核心配置

从上图可以看出，我们主要依赖git提供的git submodule命令以及脚手架工具miniTools。通过git submodule update --remote将第三方库（各个业务仓库）中最新提交到指定分支的代码合并到当前仓库（发布仓库）的指定位置中。然后，通过脚手架工具miniTools执行预定义的脚本文件，具体流程如下：

图2-3 pipeline运行流程

1）获取服务端配置信息，主要包括releaseCommitHash、Size、RC（Release Candidate）数据：

• releaseCommitHash：用于版本控制，表示业务仓库在生产上使用的版本（commitHash）；
• Size：用于Size控制，对各个业务线设置了可用的最大Size值；
• RC：用于控制该业务仓库的代码是否会自动合并至发布仓库中。

2）通过releaseCommitHash拉取各个业务仓库最新的代码并进行合并，组成完整的小程序代码；

3）通过ESLint进行代码合法性检查，最大程度地避免基本语法错误；

4）通过微信官方提供的miniprogram-ci工具，进行自动化编译，删除无用代码减小体积；

5）Size检查：通过微信官方提供的miniprogram-ci的preview方法获取所有分包的大小以及测试二维码，通过计算查看当前业务仓库的代码提交是否会导致在Size超限，超限将导致发布失败；

6）RC发布权限检查：服务端返回当前业务仓库的RC值（true/false）决定了我们是否要将其最新的代码合并至发布仓库的master分支，并且是否将最新的代码压缩成zip包，上传至发布仓库的release分支作为预发布版本。最终发布仓库（weixin-auto.git）master、release分支的目录结构如下图所示：

图2-4 发布仓库weixin-auto项目目录

7）数据更新：如果RC为true并且代码成功上传之后，我们将同步更新该业务仓库的releaseCommitHash、分包Size等信息至服务端中，以便别的业务仓库可以拉到该仓库最新的代码；

8）构建结果通知：无论成功与否，构建的结果都将发送至相关的群组以及触发该pipeline的人员，如果失败，将返回详细的错误信息进行排障，成功将返回测试二维码，如下图所示：

（1）失败

（2）成功

图2-5 构建结果通知

上述步骤任何一步失败都将导致pipeline失败，通过上述流程，确保提交到发布仓库的代码均为正确无误的代码。

2.3 持续交付

目前，携程微信小程序的发布已经统一接入公司的MCD发布平台，将事先写好的python脚本在MCD平台上进行配置，临近发布节点，PMO只需到MCD平台上进行集成发布。此时MCD将自动运行我们预设的脚本，该脚本将拉取发布仓库release分支上的zip包，将其进行整理，生成体验版二维码，由PMO发给相关人员进行集成测试。

图2-6 携程MCD发布平台

测试通过后，再有PMO将代码手动提交至微信后台进行审核，至此，一次完整的常规发布流程已经完成。

三、总结

综上所述，通过仓库管理将各个业务线分割成独立的git仓库，保证业务的独立开发、互不影响；通过pipeline自动化持续集成方案并结合公司的MCD发布平台进行持续交付，大大简化了一线开发人员的开发成本，只需提交代码即可，打包、测试、上传、预览、通知等操作均由发布仓库的pipeline自动化完成，避免了人工操作的不稳定性与繁琐，确保了业务的敏捷开发以及协同合作效率。

本文仅介绍了常规业务线协同开发的流程，其实携程微信小程序早已引入了Taro这一概念，并且针对使用Taro技术栈的业务线设计了一套独有的打包方式，目前在微信小程序中运行良好，我们正在稳步向其他各类小程序（百度、头条、支付宝等）中推广。