随着小程序越来越火爆，不少公司上架了多个小程序，或者一个小程序由多人开发，但是小程序跟大多数的WEB开发环境有所区别，当小程序变得庞大复杂（比如各类电商、新闻、社区等小程序）参与人数多的时候，就会遇到一些意想不到的风险~

传统Web开发流程

• 开发dev环境
• 测试QA环境
• 线上online环境（有些公司还有“预上线hidden环境”）

小程序

• IDE工具开发环境
• 体验码预览环境
• 审核通过线上发布环境

独狼模式（一人独立开发）：区别不大~

团队模式 ：web开发一般由SA或者主程把QA测试通过的代码发布到线上，但小程序有所不同，云函数缺少权限控制、云数据库暂不支持SQL等，QA测试在未发布前无法真机测一些功能（线上支付测试、未上线的动态二维码真机测试等）~

下面跟大家分享下，我们团队是如何做的：

1、线上“云函数”被直接覆盖的问题（高风险）

风险点：云函数和小程序代码不同，没有提审发布环节，容易直接覆盖线上代码。只要有开发权限的开发者就能上传覆盖线上的云函数。

由于现在小程序中云函数使用场景和频率越来越高，云函数没有“测试环境”，部署就直接发布覆盖线上的了，且目前没有log能追踪是谁覆盖的，万一团队中某个小伙伴一失手，干掉了线上核心的云函数就直接GG了~

有人肯定会说可以“本地调试”，但现阶段本地调试有些情况是无法模拟的，比如event 自带的userInfo等~ 同时，也无法规避其他开发者误传覆盖线上的云函数。

解决方法1：建一个对照小程序

准备另外一个小程序 B，把所有配置都设置成和主小程序 A 一样的环境，所有开发人员都在B环境开发，QA测试通过后，将代码合并到A代码线上，再统一上传部署覆盖 A 的云函数。

帮助QA完成新功能的线上测试

小程序对照组 可以方便QA做线上全真测试，解决了以下问题：

• 由于新页面还未上线，动态生成小程序二维码只能在IDE工具中预览
• 订阅系统的消息推送，没办法完全模拟online环境
• 线上全真数据测试、云函数线上测试、真实线上支付测试等

这个也是主流大厂的做法，他们甚至会建多个相同配置的小程序，做功能组件及其模块化测试。

解决方法2：在云函数中新建一个dev环境

const cloud = require('wx-server-sdk')
cloud.init({
  //env: cloud.DYNAMIC_CURRENT_ENV
  env："dev-258xxx",  //制定dev环境测试
  tracerUser:true,
})

如果你是独狼开发者或者小团队，对现有云函数更新的时候，可以切换到新建个dev-xxx，本地调试完再部署上线，自测通过后，覆盖线上。
这里需要注意：目前一个小程序云环境只能建2个。

2、代码管理

风险点：并行开发，紧急修复BUG和多版本需求协同开发的问题~

多人开发常规代码线管理 有git（sourceTree），svn（小乌龟）等，我们内部有gitLab，具体操作如下：

dev可以按照版本号来，配置一个test代码线，方便QA针对后端环境的测试，最后测试通过将代码merge至master，再用IDE工具打开master代码线发布提审~

3、后端（服务器）环境切换

风险点：手动改配置文件，忘记的问题~

之前我们切换环境的时候采取的是 手动修改 config文件：

但是有次紧急修改一个BUG发布上线的时候出了问题，合并到master分支后，忘记将原本的Url.dev 改成 online，把dev环境直接发布上线，好在及时发现没有造成严重后果。

解决方案：IDE工具中的“自定义处理命令”。

点击“详情” --> “本地设置”，配置node命令，实现自动化修改发布配置，这样就不用再手动修改了，避免人为失误。

4、专人发布审核，明确备注内容

风险点：快速迭代，待审核版本过多的问题~

避免多人提交不同版本，导致提交审核版本错误，由专人（可以是开发，PM等）负责代码提交发布。同时，请写清楚备注内容，也可以减少官方审核被拒的概率。

总结

以上方法并非一定是完美/最佳的解决方案~ 都是自己实战的经验总结，需要根据具体情况来判读：团队大小、项目重要程度、开发周期、是否有支付等~

希望分享的内容能帮到大家避免一些开发风险，欢迎讨论交流~

你的赞是我继续分享的最大动力哦！^-^