评论

[填坑手册]多人开发小程序的管理和不同生产环境的风控

在实际多人开发中遇到问题的一些总结

随着小程序越来越火爆,不少公司上架了多个小程序,或者一个小程序由多人开发,但是小程序跟大多数的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等)负责代码提交发布。同时,请写清楚备注内容,也可以减少官方审核被拒的概率。

总结

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

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

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

最后一次编辑于  05-09  
点赞 8
收藏
评论
登录 后发表内容