《持续交付》笔记——第2章 配置管理

作者：蓝白云

自以为以前负责的项目做的配置管理相对公司其它项目已经够牛的了，没想到在阅读此章时才发现山外的山好多又好高啊。：）

说到配置管理，我们常常想到的是源代码和一些需求文档、设计文档、测试文档等的配置管理，把它们放到版本控制库中管理起来就完事了。而这里对配置管理作了明确的定义（至少在本书范围内）：

“配置管理是指一个过程，通过该过程，所有与项目相关的产物，以及它们之间的关系都被唯一定义、修改、存储和检索。”

分“版本控制”、“依赖管理”、“软件配置管理”和“环境管理”四小节来分析配置管理的重要性，并强调软件开发没有配置管理，其它什么持续集成，部署流水线，自动化测试等根本就谈不上。

• 在“版本控制”一节中提倡我们将所有东西都提交到版本控制库中，当然如果你把整个操作系统也通过版本控制库管理起来，估计没人会拦着，但比较好的办法是操作系统的配置信息。真的没有必要把源代码所生成的二进制文件也存放到版本控制库中，这一点也是我原来在项目中向团队成员所强调的，但总是有人这么做。最好是“频繁提交代码到主干”，因为当你汇聚一定量的代码合并主干发现诸多问题时，通常你不得不加班加点，甚至无法交付版本。这让我想起我曾经加入的某个团队，明文规定每天要签入代码到版本控制库（而且还不是主干）。每天签入的代码到持续集成构建运行时不允许有测试失败，否则罚款（当然，罚的款项当成团队的活动经费了）。结果大部分团队成员都没有执行这个规定，而是等到要交付给测试组时才提交自己本地的代码。可想而知，测试组的成员和开发组成员在干什么了。
• “依赖管理”提到了第三方库文件，以及其它团队开发的模块或组件间的关系的配置管理。仅是抛砖引玉，详细的要到第13章了。
• “软件配置管理”，先阐述了配置与灵活性的关系，好比平衡游标，一端是没有配置的单一软件，而另一端是编程语言（这就是灵活性）。而大部分软件就是在这两点之间。记得原公司某同事提过类似的问题，他说希望做一个调度任何对象的非常灵活的测试调度器：有条件，可循环，顺序地执行任何别人想要的。我说那样话就已经是编程语言了。然后列出了软件配置的分类，告诉我们如何更好地获取配置信息，为配置建模，如何管理跨应用的配置。最重要的是我们要把配置信息当成源代码看待，并对它进行测试。
• 最后还重点描述了我们容易忽视的“环境配置管理”。“没有哪个应用程序是孤岛。每个应用程序都依赖于硬件、软件、基本设施以及外部系统才能正常工作。”，“环境配置管理和应用程序同样重要。”，提倡自动化方式管理环境，其中还列出了两个代表性工具：Puppet和CfEngine。需要考虑的环境配置信息如下：
  • 应用程序对各种各样的操作系统或中间件，包括其版本、补丁级别以及配置设置;
  • 应用程序所依赖的需要安装到每个环境中的软件包，以及这些软件包的具体版本和配置;
  • 应用程序正常工作所必需的网络拓扑结构;
  • 所依赖的所有外部服务，以及这些服务的版本和配置信息;

书中提到除了源代码和配置信息外，像开发所需要的编译器、应用服务器、虚拟机以以及其它相关工具的二进制镜像也放在版本控制库中。这样可以快速地搭建开发环境，特别是为新加入的成员。总而言之，言而总之：所有与项目相关的文件（除了通过源代码或测试代码生成目标文件外，因为这个可以通过自动化构建生成）都需要作好配置管理。