08-配置管理核心落地：代码、文档、固件、资源统一配置基线

这是CMMI3系列的第四篇，聊一个很多人觉得"枯燥但逃不掉"的话题——配置管理。
代码版本乱了、固件刷错版本了、文档跟代码对不上……这些问题配置管理都能治。CMMI3里配置管理（CM）是成熟度二级就有的过程域，但到三级要求更系统。小微企业做不好配置管理，等于裸奔。

一、配置管理在CMMI3中的核心地位

1.1 什么是配置管理

配置管理（Configuration Management，简称CM）不是"管配置文件"，而是对项目过程中产生的所有工作产品进行版本化管理和变更控制。

通俗理解：项目开发中会产生代码、文档、固件、安装包、数据库脚本、部署脚本等一堆东西，配置管理就是确保任何时候都能拿到任何一个版本的任何一件东西，并且任何变更都有记录、有审批、可追溯。

1.2 为什么小微企业更需要配置管理

大公司有专人做配置管理（CMO/CC），小微企业没有专职人员，更容易出问题：

• 客户说"上个版本是好的，这个版本有问题"，你找不回上个版本
• 硬件同事刷了一个固件，不知道是哪个版本的，跑起来行为不对
• 三个开发同时改一个文件，互相覆盖
• 交付的文档和实际代码不一致
• 上线后发现有个紧急bug要修，但已经分不清哪个分支是生产环境的

这些问题每一个都能让你加班到凌晨。

1.3 CMMI CM过程域的四个目标

CMMI3的CM过程域包含四个特定目标（SG）：

二、配置项识别：什么东西要管

2.1 配置项分类

不是所有文件都需要配置管理。配置项分为受控配置项和非受控配置项。

受控配置项（必须纳入配置管理）：

非受控配置项（不需要正式配置管理）：

• 开发过程中的临时笔记
• 调试用日志文件
• 个人本地配置（IDE配置等）

2.2 配置项命名规范

命名规范是配置管理的基础，没有规范就无法追溯。

建议命名规则：

{项目缩写}_{配置项类型}_{版本号}_{日期}_{构建号}

示例：

VEND_APK_v1.2.0_20260807_build42.apk VEND_FW_STM32_v0.3.1_20260801.bin VEND_MODEL_YOLOv8s_v2.1_20260720.rknn VEND_DB_migration_v1.0_20260805.sql

2.3 版本号规范

采用语义化版本号（Semantic Versioning）：

主版本.次版本.修订号 (Major.Minor.Patch) v1.0.0 → 初版 v1.0.1 → 修了个bug（Patch） v1.1.0 → 加了个小功能（Minor） v2.0.0 → 架构大改，不兼容旧版（Major）

固件和模型文件额外加构建号（Build Number），每次编译递增：

v1.2.0_build42 → v1.2.0的第42次编译

三、配置基线建立

3.1 什么是基线

基线是在某个时间点对一组配置项的正式快照。基线一旦建立，其中的配置项就被"冻结"，任何修改都必须走变更控制流程。

CMMI项目中通常建立以下基线：

3.2 基线建立流程

1. PM发起基线建立申请 ↓ 2. 配置管理员(CMO)收集配置项，验证完整性 ↓ 3. 生成基线清单（含每个配置项的版本号和哈希值） ↓ 4. 审批人签字确认 ↓ 5. 基线入库，打标签(Tag) ↓ 6. 通知所有干系人

小微企业可以简化：PM兼任CMO，基线建立用Git Tag + 一份基线清单表格即可。

3.3 基线清单模板

哈希值的作用：确保固件/模型文件没有被篡改。特别是固件烧录到工控板后，可以通过哈希值验证烧录的是正确版本。

四、变更控制与版本追溯

4.1 变更控制流程

基线建立后，任何配置项的修改都必须走变更控制流程（CCB流程）：

1. 提交变更申请单(CR) - 变更内容、变更原因、影响分析 ↓ 2. 变更控制委员会(CCB)评审 - 小微企业CCB可以只有3人：PM+技术负责人+客户代表 ↓ 3. 评审结论：批准 / 驳回 / 需更多信息 ↓ 4. 执行变更（在独立分支上修改） ↓ 5. 验证变更（测试+评审） ↓ 6. 合并变更，更新基线 ↓ 7. 记录变更，通知干系人

4.2 变更申请单模板

4.3 变更分类与审批权限

不是所有变更都要上CCB。按影响程度分级审批：

这个分级机制可以大幅减少CCB会议频率。C级变更日常处理，B级周报中同步，A级才正式开会。

五、配置审计

5.1 为什么要做配置审计

配置审计是CMMI CM的SG3目标，核心目的是验证配置项的实际状态与记录是否一致。

不做审计的常见后果：

• 基线清单上写着v1.0.0，实际仓库里commit已经偷偷往前走了
• 文档说有5个微服务，实际代码库里只有4个
• 交付的固件版本跟测试版本不一致

5.2 两种配置审计

功能配置审计（FCA）：验证配置项的功能是否符合需求

• 实际运行固件v0.3.1，检查功能是否与需求文档一致
• 运行APK v1.0.0，验证所有需求功能点是否实现

物理配置审计（PCA）：验证配置项的物理状态是否与基线清单一致

• 基线清单上的每个配置项是否都存在
• 版本号是否匹配
• 哈希值是否一致

5.3 审计执行建议

小微企业建议在每个里程碑前做一次配置审计，检查清单：

• 所有配置项是否都在版本控制中
• 基线清单上的版本号与实际是否一致
• 固件/APK/模型的哈希值是否匹配
• 文档与代码是否同步（API文档与接口实现是否一致）
• 是否有未关闭的变更申请
• 分支策略是否执行到位

审计发现问题要记录到配置审计报告中，跟踪闭环。

六、Git + GitLab配置管理落地实践

6.1 分支策略：简化版Git Flow

小微企业不需要完整的Git Flow，用简化版三分支模型就够了：

main ──●──────●──────●──────●──→ (生产环境，只合并Release) ↑ ↑ release ──●──────●──────●──→ (测试环境，Sprint结束合并) ↑ ↑ develop ──●──●──●──●──●──●──→ (开发环境，日常开发) ↑ ↑ feature ──●──● (功能分支，开发完合并回develop)

分支用途：

6.2 Tag管理

每次发布正式版本必须打Tag，Tag命名规范：

REL-{版本号} 如 REL-1.0.0, REL-1.1.0 REL-{版本号}-RC 如 REL-1.0.0-RC1 (候选发布版)

打Tag的操作：

gitcheckout maingittag-aREL-1.0.0-m"正式版本1.0.0发布"gitpush origin REL-1.0.0

Tag是基线的代码层面落地。基线清单中"源代码"那一行的版本号，对应的就是Git Tag。

6.3 制品库管理：固件和APK怎么管

代码在Git里管，但固件(.bin)、APK、AI模型这些二进制制品不适合放Git（体积大、diff无意义），需要用制品库管理。

方案一：Nexus/Artifactory（推荐）

• 搭建Nexus私服，按类型建仓库
• 固件/APK上传到raw仓库，按版本号管理
• CI/CD流水线自动上传构建产物

方案二：对象存储（OSS/MinIO）（轻量方案）

• 按目录结构存储：/releases/v1.0.0/apk/、/releases/v1.0.0/firmware/
• 用版本号目录区分，保留每个版本的制品
• 上传时计算MD5，写入基线清单

6.4 CI/CD与配置管理的结合

CI/CD流水线是配置管理的自动化执行者。建议配置以下流水线：

代码提交 → 自动构建 → 单元测试 → 打包 → 上传制品库 → 通知 ↓ 自动打Tag(仅release分支)

GitLab CI 示例配置（.gitlab-ci.yml 关键片段）：

stages:-build-test-package-releasebuild:stage:buildscript:-mvn clean compileonly:-develop-releasepackage:stage:packagescript:-mvn package-DskipTests-docker build-t vend-backend:$CI_COMMIT_SHORT_SHA .artifacts:paths:-target/*.jarrelease:stage:releasescript:-docker tag vend-backend:$CI_COMMIT_SHORT_SHA vend-backend:$CI_COMMIT_TAG-docker push registry.example.com/vend-backend:$CI_COMMIT_TAGonly:-tags

CI/CD的核心价值不是自动化构建，而是保证每次构建的可重复性。同一个Tag的代码，无论谁、何时构建，结果必须一致。这就是配置管理中"基线完整性"的工程化保障。

6.5 多端配置项联动管理

三端项目（后端+安卓+小程序）的配置项有依赖关系，需要联动管理：

实操建议：在项目根目录维护一个VERSION_MAP.md文件，记录每个基线下各端配置项的版本对应关系：

# Release 1.0.0 版本对应表 | 配置项 | 版本 | |--------|------| | 后端代码 | REL-1.0.0 | | 后端服务 | v1.0.0 | | 安卓APK | v1.0.0_build30 | | STM32固件 | v0.3.1 | | YOLO模型 | v2.1 | | 数据库 | migration_v1.0 | | 小程序 | v1.0.0 |

这张表就是版本对应关系的基线，出了问题先查这张表，快速定位是哪一端版本不对。

小结

配置管理是项目管理的"基础设施"，做好了你感受不到它的存在，做不好处处踩坑。

核心要点回顾：

• 配置项识别：代码、文档、固件、APK、模型、脚本全部纳入管理，命名规范统一
• 基线建立：需求基线→设计基线→产品基线→发布基线，每层都有审批和Tag
• 变更控制：分级审批（A/B/C），C级日常处理，A级上CCB
• 配置审计：功能审计(FCA)+物理审计(PCA)，每个里程碑前做一次
• Git落地：简化版三分支模型 + Tag管理 + 制品库 + CI/CD自动化
• 多端联动：API契约、通信协议、模型版本、数据库迁移脚本要跨端版本对齐