app 灰度迁移方案

需求背景

rn 项目开发效率低且维护成本高。业务模块分步骤迁移到 h5 项目，并保持业务稳定。

灰度策略

灰度目标

1. 保证新旧版本数据兼容
2. 验证系统稳定性，包括：
   • 接口报错率
   • 页面加载时间
   • 关键操作埋点数据

3. 用户反馈，做问卷调查（本次灰度不考虑）

灰度维度

• 项目维度：针对指定项目或项目下的特定路由
• 业务维度：按集团 > 店铺 > 门店 > 用户层级进行
• 版本限制：仅支持 app 版本 >= 5.9.0

放量规则

TIP

平衡影响范围与发布效率

1. 内部测试阶段
2. 小范围灰度：选择少量店铺/集团，观察 1-2 天
3. 扩大范围：逐步扩展至大型店铺/集团，观察时间 ↑
4. 全量发布：配置灰度结束时间，观察 24h 后手动确认发布完成（合并至 master）

线上问题应对方案

反馈渠道

• 埋点监控
• 数据分析
• 用户反馈

问题处理

• 一键回滚：若出现核心模块错误、操作路径阻断等问题，立即通过配置平台切换回旧版，并视情况降低灰度比例
• 热修复：针对按钮样式等明确可快速修复的问题，采用热修复方式处理

开发中遇到的问题

1. 数据兼容：新订单列表页面调用新 api 时，需差异化返回订单数据，确保新旧版本数据兼容
2. 跨栈数据传递：未迁移的 rn 页面在接收 h5 页面的上游数据时，面临跨栈（h5 -> native -> rn）传参问题（例如 function 参数）。解决方案：构建原 rn 上游实例，从实例获取所需参数，过渡项目未完整迁移的中间期