共计 3291 个字符，预计需要花费 9 分钟才能阅读完成。
保障交付效率和品质把控是一项业务久远、稳固倒退的必经之路，来自微信领取的张洪晖在第二届小程序云开发技术峰会上就介绍了高速倒退的业务团队如何利用小程序云开发搞定继续交付和品质管控。
云开发的老朋友
首先来看一下小程序的倒退规模。依据微信公布的 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 客户端等），帮忙开发者对立构建和治理后端服务和云资源，防止了利用开发过程中繁琐的服务器搭建及运维，开发者能够专一于业务逻辑的实现，开发门槛更低，效率更高。
开明云开发：https://console.cloud.tencent.com/tcb?tdl_anchor=techsite
产品文档：https://cloud.tencent.com/product/tcb?from=12763
技术文档：https://cloudbase.net?from=10004
技术交换加 Q 群：601134960
最新资讯关注微信公众号【腾讯云云开发】
