09-版本基线管理：开发基线、测试基线、发布基线、固件量产基线

这是CMMI3系列的第五篇，接着第8篇配置管理继续往下聊——版本基线。
配置管理告诉你"东西要管起来"，版本基线告诉你"什么时候该拍快照、拍什么样的快照"。没有基线，版本就是一盘散沙；有了基线，每个阶段都有据可查、有版可回。

一、版本基线的概念与作用

1.1 什么是版本基线

版本基线（Baseline）是在项目生命周期某个关键节点上，对一组配置项的正式、经过审批的快照。基线一旦建立，其中包含的所有配置项就被"冻结"，后续任何修改都必须走变更控制流程，不能随意改动。

打个比方：基线就像拍照——开发到某个阶段，“咔嚓"拍一张全景照，把当时所有代码、文档、固件、模型的状态记录下来。以后你说"去年8月那个版本”，就是指那张照片里的状态。

1.2 基线在CMMI3中的位置

CMMI3配置管理（CM）过程域的SG1就是"建立基线"，这是配置管理的第一个特定目标。没有基线，后面的变更跟踪、配置审计全都是空中楼阁。

基线的核心作用：

1.3 基线 vs Tag vs 分支

很多人搞不清这三者的关系：

• 分支（Branch）：一条平行的开发线，持续变化，是一条流动的河
• Tag：某个commit的命名标记，是河上某一点的照片
• 基线（Baseline）：一组配置项的完整快照，可能包含多个仓库的多个Tag、固件制品、文档版本等

一句话：Tag是基线的代码层落地，基线是跨所有配置项的完整快照。一个基线可能包含后端代码Tag + 安卓APK版本 + 固件版本 + 模型版本 + 数据库脚本版本，而一个Tag只对应代码仓库里的一个commit。

二、四类基线详解

在智慧农业/无人售货柜这类涉及"云-端-边"三端协同的项目中，我建议建立四类基线，分别对应开发、测试、发布、量产四个关键节点。

2.1 开发基线（Development Baseline）

定义：每个迭代/Sprint结束时建立的代码冻结节点，标志着本轮开发完成、可以进入测试。

建立时机：Sprint结束、功能开发完成、开发自测通过。

包含内容：

审批人：技术负责人。

核心特征：开发基线不是"稳定版"，而是"开发完成版"——功能写完了、编译通过了、开发自测过了，但还没经过系统性测试。

实操建议：开发基线在Git上对应develop分支打Tag，命名DEV-{版本号}：

gitcheckout developgittag-aDEV-1.1.0-m"Sprint3开发基线，完成商品识别优化和称重联动功能"gitpush origin DEV-1.1.0

2.2 测试基线（Test Baseline）

定义：从开发基线中选取，经过初步验证后正式提交给测试团队的版本标记，也称"提测基线"。

建立时机：开发基线通过冒烟测试后，正式提测前。

包含内容：开发基线的全部内容 + 测试环境部署包 + 测试用例文档。

审批人：PM + 测试负责人。

与开发基线的区别：

关键操作：从develop切出release分支，在release上做bug修复，打Tag：

gitcheckout developgitcheckout-brelease/1.1.0# 测试期间在release分支上修buggittag-aTEST-1.1.0-RC1-m"第一轮提测版本"gitpush origin TEST-1.1.0-RC1

测试期间可能产生RC1、RC2、RC3多个测试基线，每个RC对应一轮测试。最终通过的RC升级为发布基线。

2.3 发布基线（Release Baseline）

定义：测试通过、验收合格后，正式发布上线的版本标记。这是面向生产环境的"最终版"。

建立时机：UAT（用户验收测试）通过、上线审批通过后。

包含内容：

审批人：PM + 技术负责人 + 客户代表（或产品负责人）。

发布基线的核心原则：

1. 不可修改：发布基线一旦建立，绝对不允许直接修改，任何修复必须走变更流程出补丁版本
2. 可重建：基于基线的所有制品，必须能在任何时候从源码完整重新构建
3. 可追溯：每个配置项的版本号、构建号、哈希值全部记录在基线清单中

发布基线清单示例：

# Release 1.1.0 发布基线清单 建立日期：2026-08-07 审批人：张三(PM)、李四(技术负责人)、王五(客户代表) | 配置项 | 版本号 | 来源 | 哈希值(MD5) | |--------|--------|------|------------| | 后端源码 | REL-1.1.0 | Git: backend@commit a1b2c3d | — | | 后端镜像 | v1.1.0 | Harbor: vend-backend:1.1.0 | f1e2d3c4... | | 安卓APK | v1.1.0_build52 | Nexus: vend-apk/1.1.0 | a1b2c3d4... | | 小程序 | v1.1.0 | 微信平台 | — | | 数据库脚本 | migration_v1.1 | Git: db-scripts@commit e5f6g7h | — | | Release Notes | v1.1.0 | Git: docs/releases/REL-1.1.0.md | — |

2.4 固件量产基线（Firmware Production Baseline）

定义：面向设备量产烧录的固件版本锁定。这是无人售货柜/物联网项目中最特殊也最关键的一类基线。

为什么单独拎出来？

因为固件和软件不一样：

• 固件烧录到设备后，升级成本高（需要OTA或返厂）
• 固件和硬件强绑定，版本不匹配直接变砖
• 量产固件一旦出厂，无法远程回退（部分设备可能没有网络）
• 固件涉及安全认证，量产版本需要签名

包含内容：

审批人：PM + 硬件负责人 + 软件负责人 + 品控（必须多重确认，因为返工成本极高）。

固件量产基线的特殊要求：

1. 版本号必须固化到固件中（运行时可读取版本号） 2. 每个固件必须有数字签名（防止被篡改） 3. 量产基线固件必须通过全量产线测试 4. 保留至少3份备份（本地服务器+云存储+移动硬盘） 5. 量产基线建立后，产线只能烧录此版本，禁止烧录其他版本

固件版本号命名建议：

HW{硬件版本号}_FW{固件版本号}_{日期} 示例：HWV2_FW_v0.3.1_20260807

硬件版本和固件版本必须对应。HWV1的固件烧到HWV2的板子上，大概率起不来——别问我怎么知道的。

三、基线的建立、变更与审计流程

3.1 基线建立流程

1. 基线发起人（通常为PM）发起基线建立申请 ↓ 2. 配置管理员收集所有配置项，验证完整性 - 检查每个配置项版本号是否正确 - 检查二进制制品哈希值 - 检查文档是否齐全 ↓ 3. 生成基线清单（含版本号、哈希值、存储位置） ↓ 4. 审批人签字确认（根据基线类型，审批人不同） ↓ 5. 基线入库 - 代码：打Git Tag - 制品：上传制品库，标记为不可删除 - 文档：归档到指定目录 ↓ 6. 通知所有干系人 ↓ 7. 基线清单存档

3.2 基线变更流程

基线建立后，如果需要修改（比如发布后发现紧急bug），必须走基线变更流程：

1. 提交基线变更申请（说明变更原因、影响范围、紧急程度） ↓ 2. CCB评审（A级变更需CCB全票通过） ↓ 3. 在独立分支上执行变更 ↓ 4. 测试验证（回归测试 + 变更点测试） ↓ 5. 变更验证通过 → 建立新基线（版本号递增） 变更验证不通过 → 退回重改或撤销变更 ↓ 6. 旧基线标记为"已替代"，但不删除（保留历史） ↓ 7. 更新基线清单，通知干系人

注意：基线变更不是"改基线"，而是"建新基线"。旧基线永远在那儿，不会被覆盖。这就像照片拍完了不能P图，要改就重新拍一张新的。

3.3 基线审计

基线审计验证实际配置项与基线清单是否一致，分两种：

物理审计（PCA）：

• 基线清单上每个配置项是否都存在
• 版本号是否匹配
• 二进制制品哈希值是否一致
• Git Tag是否指向正确的commit

功能审计（FCA）：

• 基线版本的功能是否满足该阶段要求
• 开发基线：功能是否开发完成
• 测试基线：是否通过测试用例
• 发布基线：是否通过UAT
• 量产基线：是否通过产线全量测试

审计频率建议：

四、三端基线联动策略

无人售货柜项目涉及后端SaaS + 安卓工控端 + STM32/MCU固件三端，三端基线必须联动管理，否则版本错配就是灾难。

4.1 三端基线依赖关系

┌──────────────┐ │ 通信协议文档 │ ← 三端的"契约" └──────┬───────┘ │ ┌────────────┼────────────┐ ↓ ↓ ↓ ┌───────┐ ┌──────────┐ ┌─────────┐ │ 后端 │ │ 安卓工控 │ │ MCU固件 │ │ SaaS │ │ APK │ │ .bin │ └───────┘ └──────────┘ └─────────┘ ↑ ↑ ↑ └────────────┼────────────┘ │ ┌──────┴───────┐ │ VERSION_MAP │ ← 版本对应表 └──────────────┘

4.2 版本对应表（VERSION_MAP）

在项目根目录维护VERSION_MAP.md，每个基线对应一张表：

## Release 1.1.0 三端版本对应表 | 端 | 配置项 | 版本 | 备注 | |----|--------|------|------| | 后端 | 微服务镜像 | vend-backend:1.1.0 | 通信协议 v3 | | 后端 | AI推理服务 | vend-ai-svc:1.1.0 | YOLOv8s模型 v2.1 | | 工控 | 安卓APK | v1.1.0_build52 | 通信协议 v3 | | 工控 | YOLO本地模型 | yolov8s_v2.1.rknn | RK3588 NPU | | 固件 | STM32主控 | HWV2_FW_v0.3.1 | 通信协议 v3 | | 固件 | U-Boot | uboot_v0.3.1 | — | | 数据 | 数据库迁移 | migration_v1.1 | — |

这张表是排查问题的第一工具。售货柜出现"工控端连不上后端"，第一件事就是查这张表，看两端的通信协议版本是否一致。

4.3 基线联动的三条铁律

铁律一：通信协议变更，三端必须同步发布

后端改了通信协议（比如消息格式从v2升到v3），安卓端和固件端必须同步升级。不能出现"后端已经v3，固件还是v2"的情况。

实操：通信协议文档单独版本控制，三端在启动握手时交换协议版本号，不兼容直接拒绝连接并告警。

铁律二：固件量产基线必须和发布基线锁定

量产烧录的固件版本，必须和当时发布基线中的固件版本完全一致。不能产线烧的是v0.3.1，结果后端发布的是v1.1.0对应的v0.3.2固件协议。

实操：固件版本号在后端服务中注册，后端启动时检查已注册设备固件版本，不匹配设备标记为"待升级"。

铁律三：AI模型版本必须和固件/安卓端锁定

YOLO模型更新后，RK3588端的推理代码可能需要对应调整（输入尺寸、预处理方式等）。模型版本和固件版本必须绑定。

实操：模型文件头部嵌入版本元数据，安卓端加载模型时校验版本兼容性，不兼容直接拒绝加载并上报错误。

4.4 基线联动建立时间线

Day 1: 后端开发基线 DEV-1.1.0 Day 1: 安卓开发基线 DEV-1.1.0 ← 同一天建立 Day 1: 固件开发基线 DEV-1.1.0 ← 同一天建立 ↓ Day 3: 三端联合冒烟测试通过 ↓ Day 3: 测试基线 TEST-1.1.0-RC1 ← 三端同时提测 ↓ Day 7: 测试通过 ↓ Day 7: 发布基线 REL-1.1.0 ← 三端同时发布 ↓ Day 8: 固件量产基线 HWV2_FW_v0.3.1 ← 发布基线中的固件版本锁定为量产基线

小结

版本基线是配置管理的"骨架"，四类基线各司其职：

• 开发基线：开发完成标记，代码冻结节点，面向开发团队
• 测试基线：提测版本标记，质量门禁关卡，面向测试团队
• 发布基线：上线版本标记，不可篡改的交付快照，面向生产环境
• 固件量产基线：设备烧录版本锁定，返工成本最高，需要最严格的多重审批

核心要点：

• 基线不是"改"的，是"建"的——旧基线不删，新基线递增版本号
• 四类基线层层递进：开发基线→测试基线→发布基线→量产基线，每一层都有更高的质量门槛
• 三端项目必须维护VERSION_MAP，确保后端、工控、固件版本对齐
• 通信协议变更必须三端同步，固件量产基线必须和发布基线锁定
• 基线审计（PCA + FCA）是保证基线完整性的最后一道防线