大家好，今天小编来为大家解答软件配置管理：从ITIL、CMMI到DevOps的实践与思考这个问题，很多人还不知道，现在让我们一起来看看吧！

配置管理是什么？

说实话，不同工作经历的人对配置管理的理解和定位是不同的。下面我从几个不同的领域简单阐述一下我的理解。

ITIL中关于配置管理的定义

在ITIL（IT基础设施库，IT基础设施标准库）中，配置管理（Configuration Management）是关键组件，其定义涉及识别和记录IT服务中的配置项（Configuration Items，CI）。控制和审核过程。

具体来说，配置管理旨在确保配置项（例如计算机系统、服务器和其他资产）准确可靠，并在其整个生命周期中与其需求、设计和操作信息保持一致。这是建立和维护产品性能、功能和物理属性的系统工程。配置管理的目标主要包括两个方面：

首先是在配置管理数据库（CMDB）中维护每个IT基础设施的配置记录；二是提供配置项（CI）报告，包括问题记录、变更记录、版本信息、状态信息、关系信息等管理信息。具体来说，配置管理是基础设施和系统的所有实体（例如服务器、应用程序、存储、网络和所有托管服务）的配置、监视、管理和维护的自动化

为了使配置管理系统发挥作用，它需要某种形式的机制来存储它管理的信息。最初，这被称为配置管理数据库（CMDB）； ITIL V3 引入了配置管理系统(CMS) 的概念来取代CMDB。 CMDB 提倡单一整体存储库的概念，而CMS 提供CMDB 的概念化系统，这些系统协同工作以支持此治理流程的需求。

DevOps中关于配置管理的定义

在DevOps实践中，配置管理往往与持续集成（CI）、持续部署（CD）等自动化流程相结合，实现从代码提交到生产环境的快速、可靠、一致的部署。此外，自动化配置管理可促进跨环境的一致性，无论是开发、测试还是生产，都保持一致的设置。具体做法包括以下几个方面：

代码版本控制自动化部署（如Ansible、Puppet、Chef 等，常被视为自动化配置管理工具）依赖于管理基础设施模板（如Terraform、ARM 等）. CMMI 中的

CMMI中关于配置管理的介绍

（能力成熟度模型集成，Capability Maturity Model Integration），配置管理是保证软件产品及其开发过程和生命周期的完整性、一致性和可追溯性的重要组成部分。

CMMI 中的配置管理主要通过以下关键活动来实现：

配置识别：识别软件产品及其开发过程中的各种配置项（如文档、源代码、规范、Bug等），以便这些配置项在后续的开发和维护过程中能够准确识别和引用。版本控制：通过版本控制系统（如Git、SVN等）管理配置项的变更历史，保证每个配置项都有清晰的版本信息和变更记录。这有助于在问题发生时快速定位问题根源并采取适当的修复措施。基线管理：基线是经过正式审核和批准的一组配置项，作为后续开发的基础。在CMMI中，基线管理涉及基线的建立、变更和验证，以确保软件产品能够满足预定的质量标准和不同阶段的要求。配置审计：通过配置审计来检查基线中配置项的版本是否正确一致、位置是否正确、与其功能描述是否一致等，有助于保证软件的完整性和一致性产品并减少潜在的风险和问题。 CMMI中的配置管理强调对软件产品及其开发过程的全面控制和管理，通过技术和管理手段保证软件产品的质量和可维护性。

不同的“配置管理”解决不同的问题

ITIL领域的配置管理-对IT资产进行管理，控制日常变更

配置管理主要解决以下问题：

配置管理工具可以改进组织的变更影响分析并减少因生产变更而导致的停机时间。配置管理结合了高效的服务模型、配置项相互依赖关系的映射以及配置项和更改请求之间的关联，以帮助在中断期间更快地恢复服务。配置管理系统在设备的历史操作及其使用和修改的核算中提供审计和合规性支持。

CMMI领域的配置管理-对软件研发过程变更进行管控

CMMI更多的是从宏观的角度，定义如何更规范地开展研发活动，建立项目，建立基线，如何分配代码仓库，如何管理代码/文档/Issue，如何审批我不是CMMI专业人士，只是粗浅的了解。

下图是在网上找到的某项目管理软件中配置管理的截图。现实中，估计很多组织都会使用excel表格，通过一些流程系统来管理这项活动。

DevOps领域的配置管理 -从自动化工具层面跟踪变更，一切皆代码

CMMI从宏观角度提出了规范性要求，但似乎并没有告诉组织如何实施？另外，CMMI的配置管理思想仍然基于“集中代码管理”。似乎并没有涉及到以git为代表的“分布式代码管理”，所以实际实现中偏差会更大。对此，欢迎留言讨论。

在DevOps体系中，软件配置管理是“全自动化”的基石（PS:更脚踏实地，直面问题）。总结就是：把一切都纳入配置管理，遵循软件配置管理的三个基本原则：一切都有版本；共享单一可信来源；标准化和自动化。

**1）任何事物都有版本，**指的是：当你需要更快地发布软件时，你需要管理生产软件过程中的相关内容，而不仅仅是源代码、配置文件、运行数据，还包括：测试工具包或测试类库、测试相关代码、测试数据、测试脚本等。

**2）共享单一可信来源，**是指整个组织需要管理研发团队的所有仓库：需求仓库、代码仓库、软件包仓库。所有团队成员都应该以这些仓库中的内容作为相互沟通的基准。协作确保所有成员收到一致的信息。软件包仓库分为三种类型：临时产品仓库、正式发布包仓库、外部软件包私服仓库。

3）标准化和自动化是指：软件配置管理应制定相应的标准和规范，如：分支策略、分支命名、分支标签命名、产品功能命名和存储位置、源代码目录结构等。了解并遵守这些标准和规范，不仅可以减少不必要的沟通成本，还可以使更多的日常操作自动化，从而释放更多的人力资源，大大减少人工操作所需的时间。各种错误都会出现。

总之，通过DevOps 工具和实践正确使用和实施配置管理可以保证控制、准确性、可跟踪性、可恢复性、一致性、效率和版本控制。

检验研发团队是否做好了配置管理

您可以通过以下5个问题来验证研发团队是否已对所有内容进行版本控制：

Q-1：产品源代码和测试代码是否放入版本控制系统？ Q-2：软件应用程序的配置信息是否放入版本控制系统中？ Q-3：各种运行环境的系统配置是否放入版本控制系统中？ Q-4：自动化构建和部署脚本是否放入版本控制系统中？ Q-5：软件包版本是否受管理？研发团队也可以尝试一个挑战来测试软件配置管理是否做得足够好：

Q-S1：只要从源码仓库中签出产品源码，是否可以一键自动构建完整的应用程序包？ Q-S2：在没有其他人帮助的情况下，任何研发团队成员是否可以一键自动构建应用软件系统来体验新的产品功能？

对于软件配置管理落地的思考

上面从各个维度介绍了配置管理的定义和实践，但是它的实现呢？这就是我写这篇文章的原因。我找到了两个招聘信息来说明这个问题

”配置管理“靠流程（人）还是靠工具？

传统配置管理(CMMI) 仍然更多地依赖[人]来[保护]流程和规则。如果组织/团队规模较小，或者技术架构统一，没有平台自动化能力，靠[人]过[守卫]也可以（PS:的前提是大家尊重流程和协议） 。

如果团队很多，技术栈很多，想要靠人几乎是不可能的。即使借助一些工具，也确实取决于“配置管理工程师”的水平。

“配置管理”与组织架构

估计只有规模较大的公司才有所谓的“配置管理工程师”角色。那么哪个部门适合这个角色呢？

分配到组织级管理部门：居于寺庙顶层，基本扮演主管角色，对实际项目研发活动的掌控力非常弱。如果业务/团队很多的话，基本没什么用。分配到研发团队：如果团队规模较大（比如100人以上），业务单一，这个人基本上会融入研发团队，更加熟悉业务。

“配置管理”的未来还是团队自治

作为一名DevOps实践者，我更喜欢弱化“配置管理”流程本身。更广泛地说，“配置管理”不就是你们整个研发流程吗？从问题到代码，再到产品和环境，哪个环节留下了“变化”？配置管理的核心其实就是“控制变更”。

因此，围绕改变做文章（创建规则和工具）。简单来说，我告诉团队某个问题需要回滚，我可以在短时间内（5分钟之内）找到稳定版本（或者快速生成稳定版本），并快速部署到指定的地方环境。基本上“配置管理”已经完成。否认它，配置管理计划/更改就是一纸空文。

用户评论

蝶恋花╮

这篇文章写得真棒！从ITIL, CMMI 到 DevOps 的演进路径看得清清楚楚，特别是对实际应用场景的分析很有帮助。我公司现在正处于转型期，一直在探索软件配置管理最佳实践，这篇文章让我收获良多。

    有7位网友表示赞同！

优雅的叶子

我一直觉得DevOps 和配置管理是密不可分的，这篇博客写得很好，解释了他们在过程中互相影响的关系。不过对于不同组织实施DevOps时面临的文化挑战和技术瓶颈，能再深入些就更好了！

    有13位网友表示赞同！

凉话刺骨

以前只听过ITIL，没想过还有CMMI这种体系，这篇文章让我开阔眼界！想问一下实际操作中这些框架之间如何衔接？哪种适合中小企业的实践？

    有6位网友表示赞同！

墨染天下

软件配置管理太重要了，如果搞不好会让项目陷入混乱。这篇博客提到的自动化、版本控制等等，都是非常关键的要素，要做好学习和应用！

    有17位网友表示赞同！

葵雨

感觉这篇文章有点像是在说教，过于注重框架本身，而忽略了实际问题的解决。配置管理最终还是为了提高开发效率和软件质量，这些才是重点吧？

    有20位网友表示赞同！

青楼买醉

DevOps 推广已经很广泛了，但很多公司在实践过程中依然遇到困难。这篇博客提到的实践案例很有参考价值，能够更好地帮助我理解如何更好地将 DevOps 原理应用到实际工作中。

    有5位网友表示赞同！

一点一点把你清空

说句实话，对于ITIL和CMMI，我觉得它们已经有点过时了。现在软件开发节奏太快了，这些古老的框架反而让人束缚。DevOps 才是未来发展的趋势，更加灵活、高效…

    有11位网友表示赞同！

龙吟凤

这篇文章说得很有道理！配置管理确实关系到整个项目的成功，我们不能忽视它的重要性。下一步应该如何规范和提高配置管理效率呢？期待作者后续分享更多实践经验！

    有20位网友表示赞同！

酒笙倾凉

我比较好奇一下 CMII 中的评估体系具体是如何运作的？以及如何量化软件配置管理的效果？

    有11位网友表示赞同！

孤廖

写得很有深度，将ITIL, CMMI 和 DevOps 的关系梳理得非常清楚。作为一名参与软件开发的工程师，更加理解了配置管理的重要性，在以后的工作中会更加注重它的规范和执行！

    有9位网友表示赞同！

红玫瑰。

文章内容比较专业，不太适合我这样的初学者来阅读…希望作者可以提供一些更通俗易懂的学习资源！

    有19位网友表示赞同！

追忆思域。

虽然 DevOps 的理念非常吸引人，但是实际实施的过程还是有很多挑战。这篇文章提到了很多问题，也让我对未来在公司如何推动 DevOps 变革有了更清晰的认识！感谢分享！

    有19位网友表示赞同！

何必锁我心

我喜欢作者提出的观点，将配置管理和 DevOps 相结合，能够更好地提高软件开发效率和质量。在实践过程中，哪些工具可以有效地帮助我们实现此目标呢？期待作者进一步解答！

    有19位网友表示赞同！

〆mè村姑

我公司一直沿用ITIL体系进行配置管理，现在听说CMMI和DevOps也越来越流行了，感觉自己知识面还是有限…这篇博客让我对这些新理念有了初步了解，希望能有更多机会学习和实践！

    有7位网友表示赞同！

拉扯

对于初学者来说，这篇文章写的太学术性强了，有些概念很难理解。希望能提供一些更易于吸收的学习资源或者案例分析！

    有20位网友表示赞同！

焚心劫

软件配置管理确实是一门学问，需要不断学习和实践才能 mastery! 这篇文章对各个框架的介绍很有帮助，尤其是对实际应用场景的解析非常实用， 期待作者以后继续分享更多经验！

    有19位网友表示赞同！