10-小程序版本管理体验版、正式版、灰度发布、版本回滚机制大家好我是黒漂技术佬。上回聊了固件的版本管理这次我们把视角拉回服务端——微信小程序的版本管理。同样是多端项目小程序的管理逻辑和固件完全不同但核心心法是一样的每个版本都要有退路。一、小程序版本的生命周期一个无人售货柜小程序从代码提交到用户看到要经历以下阶段开发版 → 体验版 → 审核版 → 正式版开发版开发者工具里实时预览的版本。每次保存代码就刷新不经过任何审核。可以调用wx.getAccountInfoSync()获取当前环境信息做条件判断。体验版上传代码后在小程序后台设置体验版。体验版有一个固定的二维码扫码进入的是你上传的最新开发版本。体验版会忽略审核状态但有一个限制——只有体验者白名单里的微信号才能打开。审核版提交审核后微信官方审核团队会检查你的小程序。这个过程通常在1-7天不等。审核期间线上用户看到的仍然是之前的正式版不受影响。正式版审核通过后点击发布替换线上正式版本。所有用户访问小程序时都会拉取最新版本。注意发布操作是即时生效的没有撤回按钮。二、体验版/正式版的切换逻辑在实际开发中我们经常需要让不同的人看到不同的版本。微信提供了两种机制1. 小程序版本切换后台版本管理页面分为三个Tab开发版本、审核版本、线上版本。开发版本你上传的所有代码记录每次上传生成一个新版本号审核版本已经提交审核但还没发布的状态线上版本当前全量用户正在运行的版本2. 自定义版本号上传代码时可以指定版本号// project.config.json{setting:{version:v2.3.1}}我们的命名规范主版本.次版本.修订号-环境标记例如v2.3.1-release、v2.3.1-beta、v2.4.0-rc13. 客户端缓存策略小程序客户端会缓存代码包。新版本发布后用户不会立刻看到——微信会在合适的时机通常是下次冷启动或切后台再切回来时自动更新。这种机制虽然省流量但意味着新旧版本会有一定时间的共存期。如果新旧版本的接口协议不兼容就会出现诡异bug。解决方案接口强制带版本号Header。wx.request({header:{X-App-Version:2.3.1,}});后端根据版本号判断是否兼容不兼容就返回特定错误码前端提示用户请重新打开小程序。三、灰度发布先让20%用户当小白鼠全量发布的风险太大灰度的本质是小流量验证。方式一云开发灰度如果你用的是微信云开发后台提供灰度百分比设置。比如设置20%新版本只对20%的用户可见观察一段时间无异常后逐步调到100%。方式二自建灰度策略我们用的方式更灵活的做法是在服务端控制灰度。基本思路后台配置灰度规则用户OpenID尾号、地域、设备型号等小程序启动时调用云端接口获取当前用户应使用的版本后端返回当前最新版本号小程序本地判断是否需要触发更新// 小程序启动时获取版本策略wx.cloud.callFunction({name:getVersionPolicy,success:(res){const{targetVersion,forceUpdate}res.result;if(forceUpdate){wx.showModal({title:版本更新,content:检测到新版本请更新后使用,showCancel:false,success:(){wx.getUpdateManager().applyUpdate();}});}}});注意小程序本身的代码灰度只能通过微信官方机制实现服务端灰度控制的是接口路由和功能开关。换句话说同一个小程序包可以通过服务端配置呈现出不同的功能行为——这才是灰度真正的威力。灰度监控指标API报错率按版本号分组支付成功率页面PV无异常波动用户反馈投诉量某个灰度版本API报错率超过0.5%就触发报警立即暂停灰度扩散。四、版本回滚你的后悔药在哪里小程序没有官方一键回滚功能所以我们需要自建回滚机制。方案A服务端切换正式版本号最直接的方式——保持上一个稳定版本的代码包已发布不同路径后端配置一个current_version字段当需要回滚时直接修改这个字段指向旧版本号。小程序端每次启动都同步最新版本号如果发现服务端下发的版本号比当前低自动触发降级。方案B保留回滚分支我们的做法main分支每发布一个版本同时打Tag并创建一个hotfix-{version}分支。一旦紧急回滚直接从Tag重新构建发布。方案C云端功能开关最重要这是防患于未然的机制。所有新功能用开关控制回滚不需要发布代码只需关掉开关// 云函数返回功能开关配置{newPricingModel:false,// 新计价模式 → 关闭faceRecognition:true,// 人脸识别 → 保持开启dynamicAdBanner:v1// 广告位 → 切回旧版}五、无人售货柜小程序迭代实战说说我们的版本迭代流程需求评审→ 拆分为可灰度发布的最小功能单元双轨开发→feature/xxx分支开发合并到develop分支上传体验版→ 开发分支代码上传白名单内测提审→ 代码冻结提交审核灰度发布→ 审核通过后先10%灰度观察24小时全量发布→ 灰度无异常后全量线上监控→ 持续观察48小时每个版本号严格记录代码版本、后端服务版本、灰度比例、发布时间、负责人、回滚预案。最容易被忽略的是回滚预案。每次发布前我们都会在飞书上写一段话“如果出了问题操作步骤是1.打开后台→2.切换到旧版本→3.清空灰度配置→4.通知运维”。发布人在群里喊一声大家都知道该找谁。版本管理就是一个习惯问题——把万一出事了怎么办提前想清楚你就能睡得安稳。我是黒漂技术佬下回见。