和普通的单个小程序开发不一样，小程序服务商，除了要完成小程序代码本身的开发，管理好小程序代码的版本之外，还需要维护旗下所有小程序的线上版本迭代。

作为垂直领域的小程序服务商，每一次小程序版本升级都是新的业务能力的推出，助力垂直领域的客户更好的使用垂直领域的服务能力。垂直领域服务商和中小型企业相互借力，更好的发挥自身的长处，进而实现商业价值。

那么如何用开放平台的接口能力实现服务商小程序的版本管理，让版本升级这件事情，不在随着旗下小程序的用户量的增加而变得日益困难呢？下面我来跟大家分享下我自己在管理旗下所有小程序的版本时的小小心得。

1 引导授权

引导用户授权小程序给平台，且在授权时注意要把一下权限包含在内。

帐号管理权限

生成带参数二维码接口，获取修改基本信息

开发管理与数据分析权限

代码开发管理，（注意此权限集只能授权给一个第三方平台，如果授权时没用显示此权限集，就需要用户先登录小程序后台取消授权给其他平台后再次扫码）

小程序·云开发管理权限集

如果使用云开发，则需要此权限

2 首次提交审核

首次提交前，先给客户设置业务域名和服务器域名。
A 直接把线上稳定版本的的templateid的代码给客户提交
B 把后期升级需要替换ext.json所需要数据准备好，如果可以根据appid查到就可以用appid作为外键即可
C 提交代码核心参数 appid templateid ext_json

3 代码包的开发

下面我们来说一下代码包的开发与测试。
根据第三方平台的审核审核机制优化规则，会采取抽样审核的快速审核机制，所以对开发者提交的版本的质量会有很高的要求。而且对于一个平台来说，自2019.9.1后，每个月可提交的小程序的额度是自然月内有限的，及时撤回也占用审核额度。代码包的质量就会尤为重要。
那么怎么提高代码包的质量呢？

A 提高自身的开发能力，写出性能稳定的代码。
B 多看小程序的开发文档，提高对接口能力的理解和应用，和接口的间的关联的理解
C 测试时要覆盖到每个分支
D 多逛社区，帮助他人，同时也知道哪些地方有不完善或者有坑，该如何避开
E 另，针对平台的整改及一些近期版本计划的公告，社区也是最先发布的

4 后期版本升级维护

当有新的功能推出上线时，需要迭代开发小程序代码，产生新的稳定版本后再给旗下小程序提交审核。用开发小程序通过真机测试后，再通过开发者工具·提交代码到第三方平台草稿箱，再添加到模板库。

这时就能得到新版本templateid。得到新版本templateid后并不是直接去给旗下小程序提交审核，而是要用内测或者开发小程序，先用新的id的代码包先提交审核，审核通过上线测试无误后，在批量给旗下小程序提交代码审核。

5代码模板的提审处理

后期对代码包的提审和首次代码包的提审是一样的维护方式。代码审核结果会下发到消息与事件通知url，此时要把审核结果记录再自己的数据库，作用有以下几点
A 查询每个版本的提审通过率，及审核期间的审核进度
B 对于异常审核的账号做记录和分析，反向去思考自己代码包存在的问题，提高平台的性能和代码包的质量
C 小程序的基本信息会影响小程序的版本审核，对于这样的小程序，只能暂缓提升新版本，给客户处理完基本信息规范符合小程序平台规范后，再重新提交审核
D 方便记录每个小程序的版本提审和通过时间
E 一般建议，审核通过的小程序可以直接提交上线。至于灰度覆盖率，大家可以根据自己的需求来决定

6代码模板的审核进度查询

通常关注以下主要指标即可：
A 旗下小程序用户的总量
B 新版本提审成功总量
C 当前版本审核通过且上线的总量

7 异常审核账号的特殊处理

前面说过我们会把审核结果分类整理。
A比如审核不通过是因为部分小程序在注册时没用根据一定的运营规范来取名字，导致审核通过但不能上线，那就需要加强对运营规范下的基本信息规范的学习。
B 审核时有些客户功能不能正常体验导致审核失败，那就要去找这些客户的共性，分析哪种客户容易出现这种审核，从而在下次提交审核时，提前把这类客户经过处理后再提交。
C 再比如，有时确实是自己代码包的测试case没覆盖到位，那么就需要找到影响体验的小程序代码的具体代码未知，优化分支逻辑。

总结

综上所属，我再管理旗下小程序版本时，采用的是工作流思维，再根据审核结果去归纳总结平台出现的问题，进而优化平台整个服务流程，提高平台的稳定性。用一张草图简述：