携程微信小程序开发 第1篇
为了降低开发成本，减少人工操作，基于微信小程序官方提供的miniprogram-ci工具，我们构建了一套自动化上传测试流程。通过在业务仓库配置webhooks，当业务仓库的发布分支（master）发生push事件时将触发发布仓库（）的pipeline，执行我们在 .文件中的设置的脚本，主要内容如下：
图2-2 核心配置
从上图可以看出，我们主要依赖git提供的git submodule命令以及脚手架工具miniTools。通过git submodule update --remote将第三方库（各个业务仓库）中最新提交到指定分支的代码合并到当前仓库（发布仓库）的指定位置中。然后，通过脚手架工具miniTools执行预定义的脚本文件，具体流程如下：
图2-3 pipeline运行流程
1）获取服务端配置信息，主要包括releaseCommitHash、Size、RC（Release Candidate）数据：
2）通过releaseCommitHash拉取各个业务仓库最新的代码并进行合并，组成完整的小程序代码；
3）通过ESLint进行代码合法性检查，最大程度地避免基本语法错误；
4）通过微信官方提供的miniprogram-ci工具，进行自动化编译，删除无用代码减小体积；
5）Size检查：通过微信官方提供的miniprogram-ci的preview方法获取所有分包的大小以及测试二维码，通过计算查看当前业务仓库的代码提交是否会导致在Size超限，超限将导致发布失败；
6）RC发布权限检查：服务端返回当前业务仓库的RC值（true/false）决定了我们是否要将其最新的代码合并至发布仓库的master分支，并且是否将最新的代码压缩成zip包，上传至发布仓库的release分支作为预发布版本。最终发布仓库（）master、release分支的目录结构如下图所示：
图2-4 发布仓库weixin-auto项目目录
7）数据更新：如果RC为true并且代码成功上传之后，我们将同步更新该业务仓库的releaseCommitHash、分包Size等信息至服务端中，以便别的业务仓库可以拉到该仓库最新的代码；
8）构建结果通知：无论成功与否，构建的结果都将发送至相关的群组以及触发该pipeline的人员，如果失败，将返回详细的错误信息进行排障，成功将返回测试二维码，如下图所示：
（1）失败
（2）成功
图2-5 构建结果通知
上述步骤任何一步失败都将导致pipeline失败，通过上述流程，确保提交到发布仓库的代码均为正确无误的代码。
携程微信小程序开发 第2篇
携程API一般返回JSON格式的数据，微信小程序需要对这些数据进行解析和处理，以满足具体的业务需求。解析JSON数据的方法如下：
以下是一个解析JSON数据的示例代码：
url: '',
method: 'POST',
data: {
_apikey_: _你的API Key_,
_apisecret_: _你的API Secret_,
_参数1_: _值1_,
_参数2_: _值2_
},
header: {
'content-type': 'application/json'
},
success(res) {
let data = ();
(data);
// 从数据中提取所需的信息
let hotelName = ;
let price = ;
(`Hotel Name: ${hotelName}, Price: ${price}`);
},
fail(err) {
(err);
}
});
携程微信小程序开发 第3篇
携程小程序以模块化的思想，根据业务线对代码进行拆分隔离，采用多 BU （业务单元）的合作模式。为了避免多人协作时的版本切换和上线测试隔离等问题，我们把一个完整的项目按照业务类别划分为多个业务仓库，如基础业务、酒店业务、机票业务、火车票业务等，相互之间不存在依赖关系；通过发布仓库将业务仓库的代码进行合并、打包、上传，该仓库中的代码为预发布版本，如图1所示：
图1 协同架构图
携程微信小程序开发 第4篇
微信小程序现在实际上是拆分成两个小团队在做的，一个小团队做关键集群的业务，一个小团队做非关键集群的业务。关键集群，主要是主流程， 下单。这个保持着非常传统的scrum节奏，因为订单是一个很严肃的事情，来不得半点玩笑。
还有一个小团队在做促销相关的开发。目前外界对小程序的认知还是：适合拉新。这一点虽然微信官方不认可，但是私下大家的做法，还是很看中了微信流量的。因为促销的变化性很大，而且非常容易惹事情，因此促销是有自己的专用集群的。而且能用webview的地方，是绝对不用原生做开发的，因为原生代码涉及到审核问题。虽然我们的审核速度还是很快的， 但是毕竟是个很不可控的行为，促销不喜欢这种不可控。
有些地方还是会用原生的，因为webview的能力有些不足。这个后面我们马上会提到。
携程微信小程序开发 第5篇
目前，携程小程序共有30+条业务线并行，上百个开发人员参与，常规发布两周一次，这么大体量的小程序以及这么快的业务迭代速度，对我们的技术提出了更高的要求。
在携程小程序的开发过程中，如何准确快速地把小程序交付给测试人员是一个繁琐的过程。按照以往的做法，开发人员将代码提交至发布分支后，还需要自行到公司的MCD（携程内部发布平台）进行发布，并且存在十几个业务线同时进行，排队打包的情况，打包完成后还要依赖PMO的发布才能获得体验码进行测试。而理想的模式是，开发人员只需要进行代码的提交即可，无需关心项目编译、打包、发布等流程。
跨团队协作，如何减少耦合，避免互相影响；数十个业务线共同维护一个小程序，而小程序必须作为整体发布，如何协调发布过程，让其有条不紊的进行将是我们讨论的重点。本文将从仓库管理、持续集成、持续交付几个方面进行详细介绍。