09-版本基线管理开发基线、测试基线、发布基线、固件量产基线这是CMMI3系列的第五篇接着第8篇配置管理继续往下聊——版本基线。配置管理告诉你东西要管起来版本基线告诉你什么时候该拍快照、拍什么样的快照。没有基线版本就是一盘散沙有了基线每个阶段都有据可查、有版可回。一、版本基线的概念与作用1.1 什么是版本基线版本基线Baseline是在项目生命周期某个关键节点上对一组配置项的正式、经过审批的快照。基线一旦建立其中包含的所有配置项就被冻结后续任何修改都必须走变更控制流程不能随意改动。打个比方基线就像拍照——开发到某个阶段“咔嚓拍一张全景照把当时所有代码、文档、固件、模型的状态记录下来。以后你说去年8月那个版本”就是指那张照片里的状态。1.2 基线在CMMI3中的位置CMMI3配置管理CM过程域的SG1就是建立基线这是配置管理的第一个特定目标。没有基线后面的变更跟踪、配置审计全都是空中楼阁。基线的核心作用作用说明没有基线的后果版本快照记录某时间点的完整状态回不去历史版本出问题找不到参考冻结控制基线后不能随意改开发者偷偷改代码版本不可控质量门禁每条基线是一道质量关卡带着bug一路冲到生产环境追溯锚点问题排查的参照物哪个版本引入的说不清交付依据正式交付物的版本锁定客户验收时版本对不上1.3 基线 vs Tag vs 分支很多人搞不清这三者的关系分支Branch一条平行的开发线持续变化是一条流动的河Tag某个commit的命名标记是河上某一点的照片基线Baseline一组配置项的完整快照可能包含多个仓库的多个Tag、固件制品、文档版本等一句话Tag是基线的代码层落地基线是跨所有配置项的完整快照。一个基线可能包含后端代码Tag 安卓APK版本 固件版本 模型版本 数据库脚本版本而一个Tag只对应代码仓库里的一个commit。二、四类基线详解在智慧农业/无人售货柜这类涉及云-端-边三端协同的项目中我建议建立四类基线分别对应开发、测试、发布、量产四个关键节点。2.1 开发基线Development Baseline定义每个迭代/Sprint结束时建立的代码冻结节点标志着本轮开发完成、可以进入测试。建立时机Sprint结束、功能开发完成、开发自测通过。包含内容配置项版本来源存储位置后端源码develop分支指定commitGit仓库安卓源码develop分支指定commitGit仓库小程序源码develop分支指定commitGit仓库数据库脚本develop分支指定commitGit仓库技术文档最新版Git仓库/Wiki审批人技术负责人。核心特征开发基线不是稳定版而是开发完成版——功能写完了、编译通过了、开发自测过了但还没经过系统性测试。实操建议开发基线在Git上对应develop分支打Tag命名DEV-{版本号}gitcheckout developgittag-aDEV-1.1.0-mSprint3开发基线完成商品识别优化和称重联动功能gitpush origin DEV-1.1.02.2 测试基线Test Baseline定义从开发基线中选取经过初步验证后正式提交给测试团队的版本标记也称提测基线。建立时机开发基线通过冒烟测试后正式提测前。包含内容开发基线的全部内容 测试环境部署包 测试用例文档。审批人PM 测试负责人。与开发基线的区别对比项开发基线测试基线面向对象开发团队测试团队质量门槛编译通过自测冒烟测试通过分支来源developrelease从develop切出稳定性中等较高Tag命名DEV-x.x.xTEST-x.x.x关键操作从develop切出release分支在release上做bug修复打Taggitcheckout 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用户验收测试通过、上线审批通过后。包含内容配置项说明源代码release分支最终commit打Tag REL-x.x.x可部署制品Docker镜像、JAR包、APK、小程序发布包部署脚本Dockerfile、docker-compose、K8s manifests数据库迁移脚本正式执行的DDL/DML脚本发布说明Release Notes记录功能清单和已知问题安装/升级手册部署操作文档审批人PM 技术负责人 客户代表或产品负责人。发布基线的核心原则不可修改发布基线一旦建立绝对不允许直接修改任何修复必须走变更流程出补丁版本可重建基于基线的所有制品必须能在任何时候从源码完整重新构建可追溯每个配置项的版本号、构建号、哈希值全部记录在基线清单中发布基线清单示例# Release 1.1.0 发布基线清单 建立日期2026-08-07 审批人张三(PM)、李四(技术负责人)、王五(客户代表) | 配置项 | 版本号 | 来源 | 哈希值(MD5) | |--------|--------|------|------------| | 后端源码 | REL-1.1.0 | Git: backendcommit 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-scriptscommit e5f6g7h | — | | Release Notes | v1.1.0 | Git: docs/releases/REL-1.1.0.md | — |2.4 固件量产基线Firmware Production Baseline定义面向设备量产烧录的固件版本锁定。这是无人售货柜/物联网项目中最特殊也最关键的一类基线。为什么单独拎出来因为固件和软件不一样固件烧录到设备后升级成本高需要OTA或返厂固件和硬件强绑定版本不匹配直接变砖量产固件一旦出厂无法远程回退部分设备可能没有网络固件涉及安全认证量产版本需要签名包含内容配置项说明STM32固件主控板MCU固件 .bin/.hex瑞芯微镜像boot.img / system.img / recovery.imgU-Boot引导加载程序设备树DTB文件AI模型YOLO .rknn 模型文件配置文件设备出厂参数SN规则、服务器地址等烧录工具烧录脚本和工具版本量产测试程序产线测试用的固件/工具审批人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量产基线是否通过产线全量测试审计频率建议基线类型审计时机审计人开发基线Sprint回顾时技术负责人测试基线每轮提测时测试负责人发布基线上线前PM QA量产基线量产前硬件负责人 品控四、三端基线联动策略无人售货柜项目涉及后端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是保证基线完整性的最后一道防线