配置管理指一个过程，通过该过程，所有与项目有关的产物，以及它们之间的关系都被唯一定义、修改、存储与检索。
使用版本控制
- 对所有内容进行版本控制（所需的支撑软件配置信息，操作系统配置信息、DNS区域文件和防火墙配置等）
配置管理是持续集成交付过程的基础。
软件配置管理
灵活性：先专注于提供具有高价值且可配置程度低的功能，冒烟测试就是一种缓解配置验证问题的方法
配置分类
- 推荐应使构建打包生成的包，面向所有环境，并不植入配置信息
应用程序的配置管理
- 将特定于测试环境或生产环境的实际配置信息存放于与源代码分离的单独代码库，需要注意配置信息的版本，一定要与相应的应用软件的版本相切尔西
- 不要把密码放在版本控制系统中
- 获取配置信息：文件系统、从某个中心仓库中获取配置信息
- 配置信息：区分应用、版本、环境，都需要满足以下：
- 新增一个环境，能为这个配置应用的新环境指定一套新的配置信息
- 新建应用程序的一个新版本，确保在部署新版本时，使用新的配置，但是一量需要回滚时，还能够使用旧版本的配置
- 将新版本从一个环境移到另一个环境，确保新环境上的新配置里有效
- 重定向到一个数据库服务器，只需要简单更改一个配置项
- 通过虚拟化技术管理环境
- 一种方法是把预生产环境的配置信息作为默认配置，其它环境通过适当的方式覆盖这些默认值，尽量减少配置项
跨应用的配置管理
每个应用程序的配置项管理都应该作为项目启动阶段的一个议题，且应维护一份应用程序配置选项索引表，记录配置项的功能，位置及生命周期，如何修改。
- 在应用程序的生命周期中，我们应该在什么时候注入哪类配置信息，要与系统运维和支持团队一同讨论。
- 将应用程序的配置项与源代码保存在一个仓库中，但要把配置项的值保存在别处，另外像用户密码这类敏感信息不应该放在版本控制库中
- 应该总是通过自动化的过程将配置项从保存配置信息的存储库中取出并设置好，这样就能很容易掌握不同环境中的配置信息了
- 配置系统应该能依据应用、版本、环境为打包、安装以及部署脚本提供不同的配置值。
- 对每个配置项都应用明确的命名习惯，避免使用难懂的名称。
- 确保配置信息是模块化且封闭的，使得对某处配置项的修改不会影响到那些与其无关的配置项。
- DRY原则。定义好配置中的每个元素，使每个配置元素在整个系统中都是唯一的，其含义绝不与其他元素重叠。
- 最少化，即配置信息应尽可能简单且集中。
- 避免对配置信息的过分设计，应该尽可能简单。
- 确保测试已覆盖到部署或安装时的配置操作。
环境管理
- 环境中各种各样的操作系统，包括其版本、补丁级别及配置设置
- 应用程序所依赖的需要安装到每个环境中的软件包，以及这些软件包的具体版本及配置
- 应用程序正常工作所需的网络拓扑结构
- 应用程序所依赖的所有外部服务，以及这些服务的版本和配置信息
- 现有的数据以及其他相关信息
当评估第三方产品或服务时，应该问自己以下问题：
- 我们可以自行部署它吗？
- 我们能对它的配置做有效的版本控制吗？
- 如何使它适应我们的自动化部署策略？
对环境的变更过程进行管理，严格控制生产环境，未经组织内部正式的变更管理过程，任何人不得对其进行修改。
应该像对待生产环境一样对待测试环境，其配置管理应该与生产环境中的配置管理一样的策略。
