携程微信小程序开发 第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的发布才能获得体验码进行测试。而理想的模式是,开发人员只需要进行代码的提交即可,无需关心项目编译、打包、发布等流程。
跨团队协作,如何减少耦合,避免互相影响;数十个业务线共同维护一个小程序,而小程序必须作为整体发布,如何协调发布过程,让其有条不紊的进行将是我们讨论的重点。本文将从仓库管理、持续集成、持续交付几个方面进行详细介绍。