08-配置管理核心落地代码、文档、固件、资源统一配置基线这是CMMI3系列的第四篇聊一个很多人觉得枯燥但逃不掉的话题——配置管理。代码版本乱了、固件刷错版本了、文档跟代码对不上……这些问题配置管理都能治。CMMI3里配置管理CM是成熟度二级就有的过程域但到三级要求更系统。小微企业做不好配置管理等于裸奔。一、配置管理在CMMI3中的核心地位1.1 什么是配置管理配置管理Configuration Management简称CM不是管配置文件而是对项目过程中产生的所有工作产品进行版本化管理和变更控制。通俗理解项目开发中会产生代码、文档、固件、安装包、数据库脚本、部署脚本等一堆东西配置管理就是确保任何时候都能拿到任何一个版本的任何一件东西并且任何变更都有记录、有审批、可追溯。1.2 为什么小微企业更需要配置管理大公司有专人做配置管理CMO/CC小微企业没有专职人员更容易出问题客户说上个版本是好的这个版本有问题你找不回上个版本硬件同事刷了一个固件不知道是哪个版本的跑起来行为不对三个开发同时改一个文件互相覆盖交付的文档和实际代码不一致上线后发现有个紧急bug要修但已经分不清哪个分支是生产环境的这些问题每一个都能让你加班到凌晨。1.3 CMMI CM过程域的四个目标CMMI3的CM过程域包含四个特定目标SG目标内容一句话理解SG1 建立基线识别配置项、建立配置管理系统、创建基线选好东西、建好库、拍好照SG2 跟踪变更跟踪配置项变更请求、控制变更改东西要走流程SG3 建立完整性建立配置管理记录、执行配置审计有记录、有检查二、配置项识别什么东西要管2.1 配置项分类不是所有文件都需要配置管理。配置项分为受控配置项和非受控配置项。受控配置项必须纳入配置管理类别具体内容存储位置源代码各端源码、脚本、配置文件Git仓库技术文档需求文档、设计文档、测试文档、接口文档Git仓库/Wiki固件STM32固件.bin、RK3588 boot.img/system.img制品库/NexusAPK安卓工控端安装包制品库/Nexus小程序包小程序发布包微信平台本地备份AI模型YOLO权重文件(.pt/.onnx/.rknn)制品库/对象存储数据库脚本DDL脚本、初始化数据脚本、迁移脚本Git仓库部署脚本Dockerfile、docker-compose.yml、K8s manifests、CI/CD配置Git仓库项目管理文档项目计划、WBS、风险登记册项目管理工具/Git非受控配置项不需要正式配置管理开发过程中的临时笔记调试用日志文件个人本地配置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.sql2.3 版本号规范采用语义化版本号Semantic Versioning主版本.次版本.修订号 (Major.Minor.Patch) v1.0.0 → 初版 v1.0.1 → 修了个bugPatch v1.1.0 → 加了个小功能Minor v2.0.0 → 架构大改不兼容旧版Major固件和模型文件额外加构建号Build Number每次编译递增v1.2.0_build42 → v1.2.0的第42次编译三、配置基线建立3.1 什么是基线基线是在某个时间点对一组配置项的正式快照。基线一旦建立其中的配置项就被冻结任何修改都必须走变更控制流程。CMMI项目中通常建立以下基线基线名称建立时机包含内容审批人需求基线需求评审通过后需求规格说明书、接口定义文档项目经理客户设计基线设计评审通过后架构设计文档、详细设计文档、数据库设计技术负责人产品基线测试通过后源代码、固件、APK、部署脚本、模型文件、文档项目经理发布基线正式发布前产品基线全部内容 发布说明 安装手册项目经理客户3.2 基线建立流程1. PM发起基线建立申请 ↓ 2. 配置管理员(CMO)收集配置项验证完整性 ↓ 3. 生成基线清单含每个配置项的版本号和哈希值 ↓ 4. 审批人签字确认 ↓ 5. 基线入库打标签(Tag) ↓ 6. 通知所有干系人小微企业可以简化PM兼任CMO基线建立用Git Tag 一份基线清单表格即可。3.3 基线清单模板配置项版本号存储位置哈希值(MD5)备注后端源码v1.0.0Git: backendcommit abc123—Tag: REL-1.0.0安卓APKv1.0.0_build30Nexus: vend-apk/1.0.0a1b2c3d4…STM32固件v0.3.1Nexus: vend-fw/0.3.1e5f6g7h8…YOLO模型v2.1OSS: models/yolov8s_v2.1.rknni9j0k1l2…数据库脚本v1.0Git: db-scriptscommit def456—需求文档v1.0Git: docs/requirementsv1.0—哈希值的作用确保固件/模型文件没有被篡改。特别是固件烧录到工控板后可以通过哈希值验证烧录的是正确版本。四、变更控制与版本追溯4.1 变更控制流程基线建立后任何配置项的修改都必须走变更控制流程CCB流程1. 提交变更申请单(CR) - 变更内容、变更原因、影响分析 ↓ 2. 变更控制委员会(CCB)评审 - 小微企业CCB可以只有3人PM技术负责人客户代表 ↓ 3. 评审结论批准 / 驳回 / 需更多信息 ↓ 4. 执行变更在独立分支上修改 ↓ 5. 验证变更测试评审 ↓ 6. 合并变更更新基线 ↓ 7. 记录变更通知干系人4.2 变更申请单模板字段示例变更编号CR-2026-007申请人张三申请日期2026-08-07变更类型需求变更 / 缺陷修复 / 优化改进变更内容商品识别接口增加称重辅助校验逻辑变更原因客户反馈纯视觉识别在遮挡场景下误差大影响分析影响AI推理接口、交易服务结算逻辑预估增加3天工期CCB意见批准纳入Sprint 4执行人李四验证结果测试通过识别准确率提升至97%4.3 变更分类与审批权限不是所有变更都要上CCB。按影响程度分级审批变更级别影响审批人A级重大影响基线、影响进度5天、影响合同CCB含客户B级中等影响多个模块、影响进度1-5天PM 技术负责人C级轻微单模块内修改、不影响进度模块负责人这个分级机制可以大幅减少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)分支用途分支用途谁来合并main生产环境代码每次合并打TagPM/技术负责人release测试环境代码Sprint结束时从develop合并PMdevelop日常开发集成分支开发人员feature/*功能开发分支命名如feature/user-login开发人员hotfix/*生产环境紧急修复从main拉出修完合并回main和develop开发人员6.2 Tag管理每次发布正式版本必须打TagTag命名规范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.0Tag是基线的代码层面落地。基线清单中源代码那一行的版本号对应的就是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:-tagsCI/CD的核心价值不是自动化构建而是保证每次构建的可重复性。同一个Tag的代码无论谁、何时构建结果必须一致。这就是配置管理中基线完整性的工程化保障。6.5 多端配置项联动管理三端项目后端安卓小程序的配置项有依赖关系需要联动管理联动场景管理方式后端API变更影响安卓和小程序API契约文档独立版本控制三端引用同一版本固件升级影响后端协议通信协议文档独立版本控制固件和后端同步升级AI模型更新影响安卓推理模型版本号在安卓端运行时校验不兼容版本拒绝加载数据库变更影响所有端数据库迁移脚本版本化后端启动时自动检查并执行实操建议在项目根目录维护一个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/CC级日常处理A级上CCB配置审计功能审计(FCA)物理审计(PCA)每个里程碑前做一次Git落地简化版三分支模型 Tag管理 制品库 CI/CD自动化多端联动API契约、通信协议、模型版本、数据库迁移脚本要跨端版本对齐