【转载】干货 | 30+条业务线,携程微信小程序如何协同开发

一、背景

目前,携程小程序共有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技术栈的业务线设计了一套独有的打包方式,目前在微信小程序中运行良好,我们正在稳步向其他各类小程序(百度、头条、支付宝等)中推广。