DevOps 有几个组件必须协同工作，团队才能实现其目标。配置管理是 DevOps“机器”的核心，也是其中的一个关键元素。

配置管理是配置项的真正来源。配置项是任何可以配置的、对项目成功绝对必要的事物。例如，源代码、属性文件、二进制文件、服务器和工具都可以是软件公司的配置项。

事实上，配置管理一词在大多数行业中都有不同的含义。例如，如果你选择汽车行业，配置管理可能指的是对制造至关重要的装配线机器的配置。另一个配置项可能是各种汽车零件的库存，因为这将在开发过程的早期进行配置。

在软件开发和管理中，配置管理是指为了项目成功而需要配置和管理的项目。

然而，配置管理可以有很多含义，这取决于讨论它的人。软件开发行业中的大多数人将源代码管理单独称为配置管理。但是，当谈到 DevOps 时，配置远不止管理源代码。本文从头到尾讨论配置管理，并研究其在 DevOps 中的作用。

配置管理过程考虑了以下广泛的活动：

1. 配置识别——首先必须识别需要维护的配置。它可以是一个手动过程，例如在公共存储库上维护源代码，也可以使用发现工具自动识别配置。

2. 配置控制— 一旦确定了配置项，就不能保证它会保持不变。配置很可能会发生变化。因此，需要有一种有效的机制来控制配置管理系统的变更。在大多数配置管理框架中，变更管理流程充当控制配置管理系统变更的监护人。

3. 配置审计— 尽管存在防止配置更改的控制机制，但仍存在绕过的方法。因此，配置审计对于密切关注配置合规性至关重要。

DevOps 横跨软件开发和运营阶段。因此，配置管理横跨这两个领域也是理所当然的。

在 DevOps 中定义配置管理的灵感来自于Jez Humble 和 David Farley 合著的《持续交付：通过构建、测试和部署自动化实现可靠的软件发布》一书。

DevOps 中的配置管理被称为“全面配置管理”，由以下部分组成：

1. 源代码存储库——主要用于开发阶段。
2. 工件存储库——在开发和运营阶段使用。
3. 配置管理数据库——在开发和运营阶段使用。

图 1：全面的配置管理

源代码存储库是所有版本代码的主要容器。除了保存所有代码外，它通常还存储测试脚本、构建脚本、部署脚本和配置文件。

一些项目还利用源代码存储库来存储二进制文件。但是，我们不建议这样做，因为根据构建的数量，可能会有大量二进制文件，并且需要以不同的方式存储它们。我将在讨论 Artifact Repositories 时讨论这个问题。

那么，源代码存储库中可以存储什么呢？简而言之，任何人类可读的内容都会进入源代码存储库。软件二进制文件不是人类可读的，因此它们被省略了。测试脚本、实际代码和配置文件都是人类可读（和可用的）的，因此它们被包括在内。

并非所有源代码存储库都一样。时代变了，技术也变了。过去的源代码存储库技术是集中版本控制系统(CVCS)。然而，许多软件开发项目仍在使用这种有些过时的技术。

CVCS 的概念是源代码驻留在中央服务器中。需要签出代码、提交更改并重新签入存储库。所有这些活动都直接在中央存储库上执行。

当今的源代码存储库技术是分布式版本控制系统(DVCS)。该技术中的源代码不仅驻留在中央服务器上，还驻留在用于开发的所有终端上。换句话说，每个开发人员都会在自己的工作站上拥有整个源代码存储库。任何合并或更改都在本地执行，并且通常是无缝执行的。

DVCS 相对于 CVCS 的最大优势在于其可用性。DVCS 无需网络连接即可运行，但 CVCS 则绝对需要网络连接。如果服务器访问受阻，开发将完全停滞。因此，CVCS 存在单点故障(SPOF)，这与 DevOps 强调持续开发和最大效率的原则相悖。

由于源代码在 DVCS 中本地可用，因此与 CVCS 相比，访问、合并和推送代码的速度要快得多。

DVCS 还允许软件开发人员在将代码推送到中央服务器并最终推送给所有其他开发人员之前与其他开发人员交换代码。

事实上，如果源代码包含长期的变更历史，那么除了开发人员终端上的存储需求之外，DVCS 没有明显的缺点。

如今，有许多现成的源代码存储库。Git 的存储库系统以及 Mercurial 是关键的 DVCS 技术。Git 可能是最受欢迎的 VCS 平台，这很可能归功于它允许同时进行多个更改的灵活性。（不再需要由各个开发人员签出和签入。）

Git 软件既可以在本地使用，也可以以各种形式托管在公共云上（例如 Bitbucket、Github 和 Gitlib）。

同时，一些仍然流行的 CVCS 源代码存储库包括 Subversion 和 CVS。

鉴于 DVCS 的兴起及其丰富的优势，各组织纷纷努力将 CVCS 工具集迁移到 DVCS。

工件存储库是用于存储二进制文件的数据库。此外，还可以在其中存储测试数据和库。源代码存储库用于存储人类可读的文件，而工件存储库则用于存储机器文件。

持续集成原则鼓励开发人员频繁将代码推送到主线。每次推送都会触发构建，从而生成二进制文件。根据项目的大小，工件仓库最终可能会有数千个二进制文件。

二进制文件管理可能很麻烦；有数千个二进制文件，发布经理应该选择哪一个投入生产？相信我，这是一项不受欢迎的任务。对于发布经理来说，工件存储库大有帮助。

怎么做？工件仓库带有两个逻辑分区，用于存储和管理二进制文件：

1. 快照
2. 发布

每次成功运行构建时，生成的二进制文件都会存储在快照存储库中。但除非项目采用持续部署方法，否则并非所有二进制文件都会被推送到生产中。推送到生产中的二进制文件首先会移入发布分区，然后再部署到生产中。（见图 2。）

图 2：工件存储库

该图显示每次构建成功时都会生成各种二进制文件。此示例中的二进制文件名为 Binary 0.x，并存储在 Snapshot 分区中。并非每个二进制文件都会被推广到生产环境中。

升级的二进制文件将从快照分区移至发布分区。示例：二进制文件 0.3 和二进制文件 0.5。

这是发布管理流程的关键。假设 Binary 0.5 部署到生产环境中，部署失败。作为后备步骤，部署必须回滚到上一个版本。

以前使用的二进制版本存储在 Release 分区中，从而使得计划和执行发布变得高效。

如果没有逻辑分区，想象一下需要进行哪些规划并付出哪些努力才能在生产中识别出以前的版本并将其回滚。

配置管理数据库( CMDB) 来自信息技术基础设施库 (ITIL) 服务管理框架。CMDB 是各种基础设施设备、应用程序、数据库和服务的存储库。它不仅仅是一个清单，还承载着 CMDB 内各个元素之间的关系，如图 3 所示。

图 3：CMDB 图解

在上图中，服务、应用程序、数据库和服务器由不同颜色的框表示。图中，服务 1 依赖于应用程序 A，如箭头关系所示。应用程序 A 利用数据库 1。应用程序 A 和数据库 1 都驻留在服务器 A 上。

然而，在实际的 CMDB 中，箭头的含义与所描述的关系不同。例如，应用程序通常使用数据库 — 这是两个实体之间的关系。驻留在服务器上的应用程序会导致依赖关系。应用程序之间的数据流关系（表示在应用程序 B 和应用程序 C 之间）是数据依赖关系之一。

当您尝试更改任何应用程序、数据库或服务器时，CMDB 特别有用。

假设您想对应用程序 B 进行更改。要进行更改，您必须首先进行影响评估。CMDB 有助于执行影响评估。在图中，假设对应用程序 B 进行了更改。影响评估将显示对应用程序 B 所做的任何更改都将影响应用程序 C，因为数据正在流经它。

如今，软件开发很少是孤立进行的。要开发的软件要么是对现有代码的改进，要么是要插入企业应用程序网络。因此，准确评估影响至关重要，而 CMDB 在这方面提供了很大的帮助。

CMDB 在 DevOps 中的另一个应用是环境配置。如今，我们可以在脚本中使用 Ansible 等工具随时启动环境。当您输入生产服务器的精确配置时，环境配置工具会迅速创建一个类似产品的服务器。

但是如何才能获得服务器的完整配置呢？最直接的方法就是参考 CMDB。

假设服务器 C 是需要复制的生产服务器。在 CMDB 中，服务器 C 条目将提供服务器的完整配置，这对于编写 Playbooks（与 Ansible 兼容）等配置脚本非常有帮助。

CMDB 还具有其他优势，例如在事件解决期间为事件管理团队提供支持。CMDB 随时提供应用程序和基础架构的架构，用于排除故障和确定问题原因。

是的，没有配置管理，您就无法真正实现 DevOps。我已经分享了有关全面配置管理的原则和示例，如果没有配置管理，工件和其他有用信息就会杂乱无章、杂乱无章。

记住 DevOps 的目标 — 尽快开发软件。只有通过适当的组织和规划才能实现这一目标。全面的配置管理为您提供了足够的弹药来启动 DevOps 机器。

因此，配置管理专业人员的需求量很大。作为配置管理解决方案架构师，我并不声称自己无所不知；每个项目都会给我带来新的挑战，从而带来新的发现和学习。对我来说，这就是配置管理的魅力所在。