流程固化建立秩序，收集数据驱动改进：DevOps思维下的CMMI配置管理实践

在之前的一篇文章《配置管理：从ITIL，CMMI到DevOps的实践与思考》中，我曾经分析了不同实践体系下对“配置管理”的不同解读。今天，这篇文章主要分享下DevOps体系建设中与CMMI配置管理的碰撞，前者崇尚自动化快速交付，后者强调流程文档合规，这两者到底是水火不容呢，还是最终能够殊途同归？

从CMMI配置管理要求说起

在写这个章节时，我原本是想找些关于CMMI配置管理的概念，但在查阅资料时候有些新的发现，索性先列出来，再来详细的进行分析，有些变化也印证了我文章后面想表达的内容，

在CMMI 1.3模型中（诞生于2011年，已于 2020年9月底/10月初 正式停止评估），有关配置管理的知识点如下

和CMMI1.3相比，CMMI2.0中配置管理稍稍有些变化（特意去查了官方的文档），在开篇的实践目的表述就有不同

• CMMI1.3 表述：配置管理（Configuration Management，CM）的目的在于使用配置识别、 配置控制、配置状态记录与报告以及配置审计，来建立并维护工作产品的完整性。
• CMMI2.0 表述：使用配置识别、版本控制、变更控制和审计来管理工作产品的完整性

更明确地强调“版本控制”和“变更控制”作为配置控制的核心手段，从 CMMI 1.3 到 CMMI 2.0，配置管理的变化体现了从“符合要求（过程）”到“注重价值（实践）”的转变。

CMMI 2.0 配置管理 (CM) 实践列表

总的来说，CMMI的配置管理就是通过识别、控制、记录和审计等一系列活动，并依托于严格的基线、变更管理以及明确的计划与组织职责，来确保所有工作产品在整个生命周期内的完整性和可追溯性。

如果将上述元素进行拆解，我们可以得到如下的关于配置管理的思维导图，后面会逐步展开详解。

现实中的配置管理

上面我们了解了配置的基本概念，可能有点偏理论，让我们拉回现实。

当我们学到了这些理论，最终实际落地，发现好像缺点什么？感觉都是概念，但是又很细碎和烦碎。然后，按照配置管理计划/变更要求，设计了相应的变更流程，增加了各种角色。配置管理工具这边呢，svn/git也都在用。

最后，大家看到最多的就是类似下面的文档（配置管理计划书，配置审计报告），看上去配置管理的要素（配置项，配置审计）等等也都能对上。

实际执行却不尽如人意，配置管理的核心目标 “完整性和可追溯性“都没达到，流程规范和实际执行完全脱节，出现了如下问题。

• 交付给客户的包版本不对，引起事故；
• 某个版本的代码/交付物找不到
• 想找个某个缺陷什么时候引入的，找了一圈找不到
• 分支很多，到底该合并到哪个分支？合并冲突
• ...

那么到底是CMMI配置管理要求不合理？还是什么原因？个人认为，相当多组织的配置管理活动过于“教条”，没有读懂配置管理的内涵，没有想清楚如何落地！只是制定了配置管理规范和流程，匹配了配置管理的概念和要素，没有从研发的角度考虑，配置管理是为了什么，能带来什么好处？如果最后只是一个配置管理执行记录的文档，我想没有哪个研发团队会乐意去做，对于他们而言，这是个没什么用的“额外负担”。

配置管理是DevOps成功的基石

那么让让我们把视角拉回到研发工程领域，特别在持续交付实践中，一般提到配置管理就会想到配置管理工具ansible, puppet，或者与之对应的概念就是版本控制，依赖管理等。即使是在主流的DevOps工具平台，也很难见到“配置管理” 这个名词，即使看到，也是另外一个含义CMDB。

那么配置管理对于持续交付就不重要了吗？不然，相反它是持续交付的第一步，是基石！

在DevOps成熟度评估中，在【持续交付】这个大项上，也划分出了【配置管理】这个子项，更多是从版本控制，分支管理，构建管理，依赖管理，变更回滚等实践展开。

在乔梁老师的《持续交付2.0 业务引领的DevOps精要》一书中，也对配置管理的范围，进行了明确的划分。其中，隐约中你可能发现了CMMI配置管理中三库（开发库，受控库，产品库）的影子。在DevOps体系里，我们更多称之为“制品晋级”，构建产物一个个过“门禁”，从“不稳定”到“相对稳定”再到可以发布的状态，不就契合了三库的含义。

• 开发库是项目人员的工作环境，保存处于开发或变更的工作产品（文档或代码）。
• 受控库用于保存开发过程中某个阶段工作结束时发布的阶段产品。
• 产品库用于保存稳定的要发布的产品，例如安装和验收的产品

持续交付2.0 业务引领的DevOps精要

持续交付2.0 业务引领的DevOps精要

回到CMMI配置管理中的“配置项”的概念，配置项主要包含需求，代码，交付物，构建工具等。对照上图，持续交付过程关联的对象不正是CMMI配置管理要求的吗？

另一方面，上面的DevOps成熟度评估表中，提到了“版本可追溯性”，这和配置管理的核心目标 “完整性和可追溯性”，也完全契合。只是前者是从研发工程化实践的角度去阐述这一主张。

回到配置管理的初衷，和 “标准工业产品” 相比，软件开发尤其特殊性和复杂性。

• 软件每一次代码提交就是一个 ”新的产品“
• 持续将“非标零件”安装到持续运行的机器上，还要确保不破坏原有功能

因此 “控制变更”变得极其重要。每次代码变更都会经历一个复杂流程才能发布，包括构建、测试，代码检查，部署等。而DevOps持续交付正是通过“自动化手段”将一个配置项转化成另外一个配置项，并且自动化记录并保存它们之间的关系。

如果把“配置项”比做生产原材料，持续交付比做工厂流水线，需要记录每个环节的变化，以保证问题可以被快速定位识别。这样比喻，是不是CMMI配置管理实践就更加具像化了！

建立秩序，再谈改进

通过上面的知识的分解，你是否找到点感觉了？配置管理其实也可以更加生动形象的通过自动化手段实现。

要实现自动化，其实也面临一个问题，那就是规范化，这里就涉及到了CMMI配置管理中关于配置项的命名规则。

这里，我想表达的是，对于较大的组织来说，往往具备了一定的规则，只是可能团队A，团队B，团队C之间都有差异，对于这样的组织，本身配置管理就是个“极其细致且费功夫的活”，人为还搞出来很多差异，配置管理实践就会难上加难。

我的建议就是”先建立秩序，再谈改进“。命名规范只是个标准问题，没有谁对谁错。那么就抛开争议，先建立秩序，通过自动化/半自动化方式固化流程，收集数据，看看大家都是什么情况，为什么执行不一致，再来谈如何改进。

通过上面的理论和实践拆解分析，就可以映射出来配置管理的全场景要素。

• 配置项范围/结构/命名往往反映了实际执行情况，是客观问题的展示
• 每一个对象往往体现了背后的各种实践

配置管理的改进，本质上也是DevOps持续交付的改进，帮助组织更进一步的建立标准的工作规范，殊途同归！

选择适合自己的配置管理实践

配置管理核心思想是“控制变更，保证完整性和可追溯性”，但在不同的行业，不同的标准下，要求会略有不同。

• 对于不同行业，也有和CMMI软件配置管理类似或更加严格的标准，这里简单罗列。
  • 医疗器械行业YY/T 0664《医疗器械软件 软件生存周期过程》
  • GB/Z 42217-2022《医疗器械 用于医疗器械质量体系软件的确认》
  • 汽车行业的ASPICE模型，还会涉及到物料清单BOM的管理，配置项的范围更多
• 而在IT领域，传统企业，特别是依照CMMI体系建立的组织，往往更加强调合规性，以及日常审计；互联网或者注重快速交付的企业，更加强调可回溯性，遇到问题快速回滚。上图中，我用红圈标记的内容更多涉及“配置管理基线&审计活动相关”，具体场景就会有所差别。前者更加看重基线管理，因为客户定制太多；而后者可能会看重变更审批流程，比如上线审批单一类的。

综上所述，配置管理是个“鲜活”的研发实践，不是“死板”的概念理论，更不是为了“配置管理”而设计的各种文档。它应该体现在实践研发的工具平台上，融入研发的持续交付活动中，客观反映研发执行。CMMI2.0及最新的V3.0版本里，配置管理的实践变化也反映了这一点，提到了拥抱敏捷，拥抱DevSecOps。

总结

如下所示，回顾上面的概念和原理，以“版本”为中心建立数据关联与追溯体系，建立DevOps的“骨架基础”，那么CMMI配置管理的要求就可以融入“研发流程”进行落地。

• 分解配置管理要素，结合DevOps思想，将流程固化到平台，先串起来，至于是否规范先不管，先说有无；
• 其次打造围绕“版本”为中心的数据关联体系；
• 最后通过数据的收集，看看目前的问题都是什么，配置管理规范哪里有问题，寻找都能接受的共性方案；

另外，关于“配置管理”与“团队架构”的关系，在实践中也很重要，直接影响具体执行。由于篇幅原因，后续有时间专题介绍。