《持续交付》- 配置管理
一 什么是配置管理
配置管理是一个过程，通过该过程，所有与项目相关的产物，以及它们之间的关系都将会被唯一的定义、存储、检索和修改。
这也就意味着我们应该有一些良好的配置管理策略去对项目中的配置进行管理，这样做的好处也是显而易见的，比如：
- 我们可以完全再现所需要的任何环境（OS 的版本及其补丁、网络配置以及部署在其上的软件应用和及其配置）
- 我们可以很轻松的对这些配置进行修改，并可以将这些修改部署到任意一种环境中
- 我们可以很容易的看到已被部署到某个具体环境中的某次修改，并可以追溯到修改源，谁做的修改，什么是做的修改。
二 使用版本控制
版本控制系统是保存文件多个版本的一种机制。也就是说当我们在修改某个文件之后，我们仍然可以访问该文件之前的任意一个修订的版本。
使用版本控制系统的目的：
- 保存每个文件的所有版本的历史信息，并使之易于查找。
- 使得分布式团队可以跟加高效的协作。
为了达到这样的目的，我么可以采纳下列的几条建议
1 对所有的内容进行版本控制
是对所有的内容进行版本控制，而不仅仅只是对源代码进行控制，这也是自己对版本控制的一个误区，在对源代码进行版本控制外，还应该对所开发的软件相关的产物都应该被置于版本控制之下。这些产物可能包含着测试代码、数据库脚本、构建和部署脚本、文档、库文件和应用软件所用的配置等。
只有将上述的所有内容进行版本控制，我们才可以完全享受到从持续集成、自动化部署、自动化测试到一键部署的所有好处。当然了，不是所有的东西都得提交到版本库中，比如说源代码经过编译后的二进制文件。
2 频繁的提交代码到主干
在开发中我们只有频繁的提交代码，才可以享受版本控制所带来的众多好处。一旦将每次的修改提交到版本库，那就意味着团队的所有人都可以看到这些变更，这也会促进内建质量的提高，一旦需到将代码回滚，那么我们也可以回退到离当前版本最近的可用版本，将损失最小化。
3 使用意义明显的提交注释
这样做的好处就是当构建失败的时候，我们可以很轻易的知道是谁破坏了构建，以及他为什么破坏了构建。一个优秀的注释应该包括：
- 总结性描述
- 细节性描述
- 相关问题或者bug的链接
三 依赖管理
在软件开发中，最常见的外部依赖无非就是使用第三方的库文件，而这些库文件一般都是以二进制文件的存在，不会被团队的成员所修改，这也就意味着这些依赖一般不会频繁的更新，所以我们一般也不会将这些二进制文件放入到版本库中，我们最好将其放在统一的一个本地库中。
四 软件配置管理
1 配置与灵活性
在对软件进性配置时，我们一般应该总是先专注与提供具有高价值且可配置程度较低的功能，在真正需要时在添加可配置项。
2 配置的分类
我们一般在构建，部署，测试和发布过程中任何一个阶段引入配置，不建议在构建打包时引入配置，应该保证部署之前所有的包是一样的
3 应用程序的配置管理
- 获取配置信息
让所有应用程序通过一个中央服务系统得到他们所需的配置信息 - 为配置项建模
一个配置项取决于三个方面
应用程序
应用程序的版本
运行环境（开发，测试，生产） - 系统配置的测试
- 保证外部服务都开启
- 对与配置项相关的功能进行自动化的冒烟测试
4 管理配置信息的原则
- 确定注入配置的时机
- 配置项和配置值分开存储
- 总是自动化获取配置
- 每个人应该都能容易的获取当前应用当前版本在当前环境下的配置信息
命名简单易懂 - 确保配置信息修改的模块化，改一边不会影响另一边
- 不要重复定义配置项
- 最少化配置
- 避免过分设计
- 确保对配置操作也有测试
五 环境管理
每一个应用程序都会依赖与硬件、软件、基础设施以及外部系统才能工作，而这些所依赖的东西就被称为是应用程序的环境。环境的配置和应用程序的配置应该是同等重要的。只有我们可以充分的给予了重视，我么才可能：
- 避免人员离职产生的知识遗忘问题
- 修复时间往往要耗费很长时间
- 可以保持各个环境的统一
环境管理需要考虑的配置信息：
- 操作系统（版本，补丁级别和配置设置）
- 第三方包（版本，配置）
- 网络拓扑
- 所依赖的外部服务（版本，配置）
- 现有的数据及其他相关信息
当我们在对环境配置进行管理时，我们应该建立一套自动创建的环境，这样可以使得自动创建环境比修复受损的环境要容易的多。
疑问
对软件配置的管理这个概念还不是很清楚。
