保证交付效率和质量把控是一项业务长远、稳定发展的必经之路，来自微信支付的张洪晖在第二届小程序云开发技术峰会上就介绍了高速发展的业务团队如何利用小程序云开发搞定持续交付和质量管控。
云开发的老朋友
首先来看一下小程序的发展规模。根据微信发布的 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 客户端等），帮助开发者统一构建和管理后端服务和云资源，避免了应用开发过程中繁琐的服务器搭建及运维，开发者可以专注于业务逻辑的实现，开发门槛更低，效率更高。