《持续交付》第二章 配置管理

本章主要讨论以下三个问题

• 为管理应用程序的构建，部署，测试和发布过程做好准备
  对所有内容进行版本控制；管理依赖关系
• 管理应用软件的配置信息
• 整个环境的配置管理

版本控制

进行版本控制的目的

• 保留每个文件的所有版本的历史信息，团队协作不受时间和空间的限制
• 大大减小了时间和空间对团队间协作的限制

版本控制的原则

• 对所有内容进行版本控制

• 版本控制不仅仅针对源代码，每个与所开发的软件相关的产物都应被置于版本控制下

• 我们的目标是能够随时获取软件在整个生命周期中任意时间点的文件状态
• 每个成员都应该将与项目有关的任何文件及其修订状态保存在版本控制存储之中
• 并不推荐将源代码编译后得到的二进制文件也纳入到版本控制中
• 保存与搭建测试环境和生产环境的所有必需的信息
• 频繁提交到主干

• 频繁并有规律地向版本控制系统提交代码
• 将代码提交到主干。创建分支的做法违背了持续集成的宗旨
• 代码提交之前要做的事：在提交代码前运行测试套件；增量式引入变化，即每完成一个小功能或一次重构之后就提交代码

• 使用意义明显的提交注释

• 注释应尽可能详细，描述本次提交做了什么，以及这样做的原因

依赖管理

• 外部库文件管理。通常以二进制形式存在，对于“是否将外部库文件放到版本控制库中”这个问题，至今存在争议。其实，放与不放，各有利弊
• 组件管理。将整个应用软件分成一系列的组件进行开发，能让某些变更的影响范围比较小，从而减少回归缺陷。另外，它还有利于重用，使大项目的开发更加高效。构建流水线之间的依赖应该是二进制文件依赖，而不是源文件依赖

配置管理

我们应该以对待代码的方式来对待你的系统配置，使其受到正确的管理和测试

应用程序的配置管理

• 获取配置信息
  • 通过一个中央服务系统得到它们所需要的配置信息
  • 从某个中心仓库中获取配置信息
• 为配置项建模
  • 配置信息可以被看作是元组的一个集合。
  • 元组及其取值取决于三方面：应用程序，该应用程序的版本，该版本所运行的环境
• 系统配置的测试
  • 保证配置设置中对外部服务的引用是良好的
  • 应用程序一旦安装好，就要在其上运行一些冒烟测试，以验证运行正常

环境管理

目的：为了降低环境管理的成本和风险，有必要将环境变成可量产的对象，使对其进行的操作具有可重复性且时间是可预测的

基本原则：

• 将二进制文件与配置信息分离
• 将所有的配置信息保存在一处
• 你应该像对待源代码一样对待环境，增量式地修改，并将修改提交到版本控制中。对每个修改都要进行测试，以确保它不会破坏在这个新版本地环境中运行地应用程序

环境管理的工具

• 以自动化方式管理操作系统配置，以声明方式来定义一些事情
• 虚拟化技术也可以提高环境管理过程的效率

变更过程管理

• 应该严格控制生产环境，未经组织内部正式的变更管理过程，任何人不得对其进行修改
• 测试环境的软件配置应该非常接近于生产环境
• 我们应该使用同样的机制来管理，部署和配置这两类环境

---

总结&疑惑

• 在一个软件项目中包括源程序，依赖关系以及配置信息
• 我们通常所说的源代码指的是什么，源代码是包含配置文件和依赖文件，还是说是源代码与配置文件和依赖文件属于同等地位
• 打包与编译是否有明确的先后顺序
• 配置信息可以看作是元组的一个集合，那么元组与配置项之间的关系是什么
• 回归测试是指重复执行以前的全部或部分相同的测试工作，那么回归缺陷是否就是进行回归测试后存在的问题，缺陷回归又是什么