16-量产交付管理：工控固件发布、SaaS灰度、小程序上架管控流程

16-量产交付管理工控固件发布、SaaS灰度、小程序上架管控流程交付不是代码写完就上线很多小微团队对交付的理解停留在代码写完 → 部署上线 → 完事。但在智慧农业和无人售货柜项目里交付涉及三端——工控固件、SaaS后端、小程序——每端的发布流程、管控方式、回滚机制都不同。一个环节没管住轻则用户体验差重则设备变砖、客户退款。CMMI3的产品集成和交付管理要求有明确的发布流程和质量门禁。这篇我们把三端的量产交付流程拆开讲每端给出实操步骤和Checklist。交付管理全景图三端交付不是同时进行的有先后依赖关系准备阶段 后端SaaS灰度发布先行提供新接口 ↓ 安卓工控固件OTA升级依赖后端新接口 ↓ 小程序上架发布依赖后端安卓联调通过 ↓ 交付阶段 三端签收确认 → 量产出货为什么后端要先上因为安卓固件和小程序都依赖后端接口。如果后端没先灰度安卓OTA升级后调不通接口柜机就离线了。这个顺序不能乱。一、工控固件发布流程固件发布是风险最高的一环。固件刷进去容易出问题想收回来难——设备已经部署在客户现场总不能一台台拆回来重刷。1. 烧录验证固件在发布前必须经过完整的烧录验证分为三个阶段开发自测阶段开发工程师在本地烧录固件到测试设备验证核心功能系统能正常启动安卓桌面正常显示串口通信正常传感器数据能读到GPIO控制正常电磁锁能开关网络通信正常MQTT能连上后端摄像头预览正常如果用到YOLO视觉识别测试验证阶段测试工程师按测试用例全量执行重点覆盖功能测试开门/关门/商品识别/扣款/退款全流程稳定性测试连续运行72小时无崩溃、无内存泄漏边界测试断网/弱网/断电恢复/传感器异常兼容性测试在所有支持的硬件型号上各跑一遍UAT验证阶段用户验收测试由产品经理或客户在真实场景下试用确认业务流程跑通。2. 版本锁定固件通过所有验证后执行版本锁定版本锁定操作 1. 固件包命名规范firmware_设备型号_版本号_日期.bin 示例firmware_RK3568_v1.8.2_20260807.bin 2. 计算MD5/SHA256校验和记录在版本台账中 3. 固件包上传到OTA服务器设置待发布状态不可被设备拉取 4. 生成版本说明文档 - 版本号 - 包含的功能变更 - 修复的Bug清单 - 已知问题Known Issues - 兼容的硬件型号清单 - 依赖的后端SaaS最低版本版本锁定的核心目的是可追溯。任何时候都能查到某个版本固件包含了什么变更出了问题能快速定位。3. 出货台账量产交付时每一台设备的固件版本都要记录在出货台账中设备编号硬件型号固件版本烧录日期出货日期客户部署地址D00001RK3568v1.8.22026-08-052026-08-07XX超市上海浦东D00002RK3568v1.8.22026-08-052026-08-07XX超市上海浦东D00003RK3288v1.8.22026-08-052026-08-07XX便利杭州西湖出货台账的价值在于当某个客户报告设备故障时我们能立刻知道这台设备的固件版本、硬件型号快速判断是不是某个版本的共性问题。4. OTA灰度策略固件OTA升级不是一次性全量推送必须灰度灰度阶段1选择5台设备内部测试设备→ 推送OTA → 观察24小时 ↓ 无异常 灰度阶段2选择20台设备小范围客户→ 推送OTA → 观察48小时 ↓ 无异常 灰度阶段3选择50%设备 → 推送OTA → 观察72小时 ↓ 无异常 全量推送剩余所有设备每个阶段的观察指标OTA成功率≥99%升级后设备在线率≥98%升级后崩溃率≤0.1%业务功能异常率0%任何指标不达标立即停止灰度排查问题。已升级的设备触发回滚。5. 固件回滚机制固件必须有回滚能力。我们采用A/B分区方案设备存储分区 ┌──────────┬──────────┬──────────┐ │ Boot A │ Boot B │ Data │ │ (当前运行) │ (备用/新) │ (用户数据) │ └──────────┴──────────┴──────────┘ OTA流程 1. 新固件写入Boot B分区 2. 重启时从Boot B启动 3. 启动成功 → 标记Boot B为活跃分区完成升级 4. 启动失败/3次crash → 自动回退到Boot A自动回滚这套方案在瑞芯微平台上完全可以实现A/B分区是Android标准特性。OTA变砖的风险基本消除。二、SaaS灰度发布后端SaaS的发布相对成熟SpringBoot 容器化部署灰度方案选择多。1. 发布前准备发布前Checklist □ 代码Code Review通过 □ 单元测试覆盖率≥80% □ 接口自动化测试全通过 □ 数据库Migration脚本验证 □ 配置文件检查生产环境配置 □ 监控大盘就绪关注核心指标基线 □ 回滚脚本准备就绪2. 灰度发布策略我们根据发布类型选择不同的灰度策略金丝雀发布Canary Release适用于大版本更新风险较高的发布阶段1生产环境部署1个新版本实例共10个实例 → 路由5%流量到新版本 → 观察30分钟监控错误率、响应时间、业务指标 阶段2扩大到3个实例 → 路由20%流量 → 观察1小时 阶段3扩大到5个实例 → 路由50%流量 → 观察2小时 阶段4全量切换 → 所有实例升级到新版本 → 观察24小时关闭旧版本滚动更新Rolling Update适用于小版本更新、Bug修复逐个实例替换 实例1(旧) → 实例1(新) → 健康检查通过 → 继续 实例2(旧) → 实例2(新) → 健康检查通过 → 继续 ...直到所有实例替换完成Kubernetes的Rolling Update策略天然支持这种方式配合 readinessProbe 做健康检查实现零停机发布。3. 监控与回滚灰度期间的监控指标指标正常基线告警阈值回滚阈值API错误率(5xx) 0.1% 0.5% 1%平均响应时间 200ms 500ms 1000ms订单成功率 99% 98% 95%支付回调成功率 99.5% 99% 98%MQTT消息积压 100条 500条 2000条触发回滚时的操作回滚操作目标30分钟内完成 1. 发现告警 → 运维确认是否需要回滚 2. 执行回滚脚本kubectl rollout undo deployment/saas-api 3. 确认旧版本实例恢复正常 4. 检查数据库Migration是否需要回退 5. 通知项目组 → 记录回滚原因 → 安排修复数据库Migration回退是重点。如果发布包含数据库结构变更回滚前必须确认旧代码能不能兼容新表结构。我们的做法是数据库变更做到向前兼容——新增字段用NULL默认值不删字段不改名确保新旧版本都能跑。三、小程序上架管控流程小程序的发布和后端、固件不同要走平台的审核流程时间不可控。所以管控要更前置。1. 代码审核代码审核Checklist □ 代码Code Review通过至少一人Review □ 涉及支付/用户隐私的接口已确认安全性 □ 小程序权限配置正确scope.userLocation等 □ 无硬编码的测试环境地址 □ 分包加载优化主包 2MB □ 隐私政策已更新如果新增了用户数据采集2. 体验版验证提交审核前先发体验版由测试和产品经理在真机上验证体验版验证清单 □ 全业务流程走通注册→选商品→扫码开门→取货→支付 □ 不同机型兼容性iOS/Android各至少2款 □ 网络异常场景弱网/断网恢复 □ 支付流程完整性微信支付成功/失败/退款 □ 页面性能首屏加载 3s交互响应 500ms3. 灰度策略微信小程序支持灰度发布我们在审核通过后不直接全量上线小程序灰度策略 阶段1灰度10%用户 → 观察24小时 监控指标崩溃率、JS错误率、接口报错率 ↓ 指标正常 阶段2灰度50%用户 → 观察24小时 ↓ 指标正常 阶段3全量发布灰度期间的监控依赖微信小程序后台的数据看板同时后端SaaS也要监控来自小程序的请求异常率。4. 正式上线上线确认Checklist □ 体验版验证全部通过 □ 后端SaaS已灰度发布且稳定运行 □ 安卓固件已OTA升级且联调通过 □ 小程序审核已通过 □ 灰度策略已配置 □ 客服话术已准备常见问题应答 □ 回滚方案已确认小程序可快速回退到上一版本交付Checklist与签收确认三端都发布完成后最终交付需要走签收流程。这是CMMI3里交付管理的要求——交付不是开发说我搞完了就算数必须有书面签收。## 交付签收单 ### 项目信息 - 项目名称XXX无人售货柜系统 v2.3.0 - 交付日期2026-08-07 - 交付负责人XXX ### 三端版本信息 | 端 | 版本号 | 发布状态 | 负责人 | |----|--------|---------|--------| | 后端SaaS | v2.3.0 | 已灰度全量 | XXX | | 安卓工控 | v1.8.2 | 已OTA全量 | XXX | | 小程序 | v2.3.0 | 已全量上线 | XXX | ### 质量确认 □ 功能测试全部通过 □ 兼容性测试通过 □ 性能指标达标 □ 监控告警就绪 □ 回滚方案验证通过 ### 签收 - 开发负责人签字__________ 日期______ - 测试负责人签字__________ 日期______ - 项目经理签字 __________ 日期______ - 客户/业务方签字__________ 日期______签收单归档保存作为项目交付的正式记录。如果后续出现质量问题签收单是责任界定的重要依据。小结量产交付是项目最后的临门一脚也是最不能掉链子的一环。工控固件靠A/B分区灰度OTA保安全SaaS靠金丝雀发布监控回滚保稳定小程序靠体验版验证灰度上线保质量。三端各有各的发布节奏但最终都要汇到一张交付签收单上。小微团队不需要重型流程但这个交付Checklist和签收确认一定要做。