小程序云开发持续交付和质量管控（上）

保证交付效率和质量把控是一项业务长远、稳定发展的必经之路，来自微信支付的张洪晖在第二届小程序云开发技术峰会上就介绍了高速发展的业务团队如何利用小程序云开发搞定持续交付和质量管控。

云开发的老朋友

首先来看一下小程序的发展规模。根据微信发布的 2019 年度报告，小程序在当年带动了 536 万就业，对社会的贡献很是大，更可观的是它的同比增加达到了 195%，能够看到小程序生态发展地很是迅猛。

我所在的团队是微信支付境外团队，团队出品的境外游礼包项目的重要载体之一就是小程序，它能够支持用户到全世界各地均可以获取咱们的汇率优惠和优惠券以及礼包优惠。

做为第一批使用云开发的团队，称得上是云开发的“老朋友”。总的来讲，从传统的小程序开发模式，切换到云开发模式以后，咱们的产出率增加了将近三倍。

你们可能会有疑问，为何在切换到云开发模式后，产出率会增加这么多？要回答这个问题，先来看一下传统的开发模式是怎样的。

开发模式对比

传统的开发模式中，前端须要负责小程序的 UI 以及逻辑构建，由后端来实现 CGI 和后端服务，而产品经理提需求，须要给前端同窗提一遍需求，同时也要给后端同窗同步需求，这里就增长了沟通成本。

需求定下来以后，前端和后端的同窗是须要进行沟通协做的，这里也存在必定的沟通成本，另外因为后台服务很是注重稳定性，须要作好风险把控，因此灰度流程会比较长。

上述的种种状况对团队的开发效率存在必定影响，而在切到云开发模式以后，咱们的开发流程被大大简化了：

后端同窗只须要关注后台的服务，而 CGI 这一层彻底由云函数去进行承担，大部分场景下，产品需求只须要一个前端同窗就能够完成了。另外，因为前端同窗作全栈的开发，也省去了协商沟通的成本。

这对后端同窗也是很是有益的，目前在这种模式下，后端同窗能够更关注于服务的稳定性以及提供一些能力，让运营的玩法需求所有交给前端同窗去作。

团队应用云开发的痛点

通过一年的高速发展，项目用户不断增多，团队不断壮大，项目中使用的云函数的数量也不断在增长，让咱们看到了一些隐患。

第一，项目发布没有审批。例如，在开发者工具上右键点击上传，查不到具体是由谁发布，这时也没有额外的审批环节，可能会致使发布错了以后难以溯源。

第二，云函数是相互独立的。为了一些逻辑的互用，会提供一些公共的代码，这些公共的代码是经过脚本下发的方式来下发各个云函数，这种方式有效提升了代码复用率，可是反过来，若是发布前忘记下发步骤，可能会致使代码残缺。

第三，咱们的云函数的上传方式是在开发者工具里点击右键完成上传。因为项目云函数数量很是多，一个个点击和发布很是耗费时间，在十分顺利的状况下每每都须要两个多小时进行部署和确认。

总结来看，项目小程序的部署发布效率比较低，该如何去提高呢？此外，当流程较多时，须要注意的要点也很是多，该如何保证不出错呢？

持续交付

这里团队就引入了持续交付的概念，得以让咱们又好又快地使用云开发。

上图是持续交付流水线的总览。触发构建以后，经过手动触发的方式，进入二级的审批流程，接着咱们会去仓库里面拉主代码，拉完代码以后，还会有一系列的代码检测和测试。

测试经过以后，才会去走小程序和云函数两条发布的流水线，发完以后会将版本发布的消息同步给你们。

看到这里，你们可能会有一个疑问：为何要用手动触发这种方式呢？它的效率是否是很低？

确实，除了手动触发这种方式，其实还有 git hooks 这种自动触发的方式，它的效率相对来讲会比较高。

关于这个问题，团队也进行了多维度的衡量与思考，结论是：自动触发方式更适合的场景是测试环境，由于它对稳定性的要求并无那么高，可是它须要即时去同步一些新的特性，最终，咱们在测试环境以及产品体验的环节使用了自动触发的方式，但真正对外进行发布的时候，咱们会用手动触发的方式保证质量，而且会有二级审批的流程。

高效部署

说到触发，上文讲到一个一个点击云函数的部署方式效率很是低，那么咱们如何去作到高效地部署云函数呢？

首先，团队使用了云开发提供的 CloudBase-manager-node 等基础库，并基于此封装了获取云函数列表、部署单对云函数以及全量部署云函数等能力。

同时在小程序一侧，利用 miniprogram-ci 这一自动化部署能力，封装了自动上传代码包，优化了用开发者工具上传的步骤，但在发布以前，会提早去下发公共代码，以保证代码的完整性。

自动部署这种方式的效率很是高，用起来也很是爽，但若是发布引入了一些 bug，可能会出现不少严重的后果，所以在持续交付过程当中咱们还引入了灰度发布的能力。

灰度发布

在初始化的时候，咱们的小程序和云函数，会有小程序的新版本，云函数有两个环境：灰度环境和正式环境，现网的用户拿到了现网的小程序版本，咱们能够放心的把一些新的云函数特性部署到灰度环境，把路径指到灰度环境。

当开始灰度时，咱们会慢慢扩大灰度比例，把流量慢慢导入到灰度环境，同时现网的用户拿到旧版本的比例有必定程度的降低，团队也要看一下监控以及指标是否有问题，有问题的要快速进行回退。

当灰度完成的时候，现网全部的用户拿到的都是正式版本的小程序，这个版本是 100%流量访问灰度环境。刚才所谓的灰度环境，这时候就变成了正式环境，而正式环境就变成了灰度环境，也即完成了蓝绿发布的一个切换，当进行下一次进行发布的时候，就能够把新的特性部署到咱们的灰度环境。

这种设计有很是大的优点，你们能够思考一下。第一，它控制了变动的风险，能够及时快速的进行回退；第二，客户端和云函数是一块儿进行灰度的，即便须要作一些破坏性变动，例如协议变动时，也彻底不用担忧线上的小程序版本是否兼容新的协议；第三是基于灰度设计的能力，适合作一些产品特性的快速验证。

有了总体灰度的能力以后，你们可能会问，是否有对云函数单独灰度的能力？固然，咱们也设计了云函数单独灰度的能力。

能够看到，咱们的小程序带着版本号过来访问，会请求到 getCloudEnv 这样的云函数，其实这个云函数没有作一些复杂的逻辑，只是单纯的去云 DB 里面去获取当前这个版本应该访问到哪一个环境，这里就会对灰度的比例以及白名单用户进行一个判断。

当咱们带着版本号返回到前端的时候，前端小程序就会根据这个版本号去访问到对应的灰度环境，团队也是基于此设计了云函数的单独灰度。

这里给你们看一下效果：下图中，纵轴是灰度比例，横轴是时间线，能够看到红色这条曲线是灰度比例，从 0 慢慢地放大到了 100%；而绿色这条曲线，当蓝绿发生切换的时候，流量从 100%慢慢降低到了 0。

除了用灰度发布来控制变动风险，还有不少质量检测的一些能力。好比说 Lint 检查，防止代码风格发生一些问题；自动化测试，来防止代码变动影响现网的功能；还有一些代码报告等。

最后，看一下持续交付的总体效果，在引入这条流水线和持续交互以后，代码顺利变动了 150 余次，有效支撑了产品的迭代。

另外，部署时间也从原来的两个小时缩短到了 5 分钟，这大大节省了研发的人力。此外，在引入流水线以后，实现代码变动 0 故障，让发布也更加安全。

以上是实践案例的上半部分，下半部分将着重介绍团队如何作好质量管控，敬请关注。

产品介绍

云开发（Tencent CloudBase，TCB）是腾讯云提供的云原生一体化开发环境和工具平台，为开发者提供高可用、自动弹性扩缩的后端云服务，包含计算、存储、托管等serverless化能力，可用于云端一体化开发多种端应用（小程序，公众号，Web 应用，Flutter 客户端等），帮助开发者统一构建和管理后端服务和云资源，避免了应用开发过程当中繁琐的服务器搭建及运维，开发者能够专一于业务逻辑的实现，开发门槛更低，效率更高。