《持续交付 发布可靠软件的系统方法》读书笔记

配置管理

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

配置管理策略将决定如何管理项目中发生的一切变化。因此，它记录了你的系统以及应用程序的演进过程。另外，它也是对团队成员协作方式的管理。

版本控制

版本控制系统的目的有两个。首先，它要保留每个文件的所有版本的历史信息，并使之易于查找。其次，它让分布式团队（无论是空间上不在一起，还是不同的时区）可以愉快地协作。

为什么要这样做呢？

  • 对于我们开发的应用软件，某个特定的版本是由哪些文件和配置组成的？如何再现一份与生产环境一模一样的软硬件环境？
  • 什么时候修改了什么内容，是谁修改的，以及为什么要修改？因此，我们很容易知道应用软件在何时出了错，出错的过程，甚至出错的原因。

    依赖管理

    在软件项目中，最常见的外部依赖就是其使用的第三方库文件，以及该软件需要用到的正由其他团队开发的模块或组件间的关系。

依赖管理主要包括：

  • 外部库文件管理
  • 组件管理

    软件配置管理

    软件在构建、部署和运行时，我们可以通过配置信息来改变它的行为。

交付团队需要认真考虑设置哪些配置项，在应用的整个生命周期中如何管理它们，以及如何确保这些配置项在多个应用、多个组件以及多项技术中的管理保持一致性。我们认为，应该以对待代码的方式来对待你的系统配置，使其受到正确的管理和测试。

管理配置最有效的方法是让所有的应用程序通过一个中央服务系统得到它们所需要的配置信息。

下面列举了一些在对配置信息建模时需要考虑的用例：

  1. 新增一个环境（比如一个新的开发工作站，或性能测试环境）。在这种情况下你要能为这个配置应用的新环境指定一套新的配置信息。
  2. 创建应用程序的一个新版本，通常需要添加一些配置设置，删除一些过时的配置设置。此时应该确保在部署新版本时，可以使用新的配置设置，但是一旦需要回滚时，还能够使用旧版本的配置设置。
  3. 将新版本从一个环境迁移到另一个环境，比如从测试环境挪到试运行环境。此时应该确保新环境上的新配置项都有效，而且为其设置了正确的值。
  4. 重定向到一个数据库服务器。应该只需要简单地修改所有配置设置，就能让它指向新的数据库服务器。
  5. 通过虚拟化技术管理环境。应该能够使用虚拟技术管理工具创建某种指定的环境，并且配置好所有的虚拟机。你也许需要将这种虚拟环境中的配置信息作为某特定版本的应用软件在虚拟环境中的标准配置信息。

我们要把应用程序的配置信息当做代码一样看待，恰当地管理它，并对它进行测试。当创建应用程序的配置信息时，应该考虑以下几个方面：

  1. 在应用程序的生命周期中，我们应该在什么时候注入哪类配置信息。是在打包的时候，还是在部署或安装的时候？是在软件启动时，还是在运行时？要与系统运维和支持团队一同讨论，看看他们有什么样的需求。
  2. 将应用程序的配置项与源代码保存在同一个存储库中，但要把配置项的值保存在别处。另外，配置设置与代码的生命周期完全不同，而像用户密码这类的敏感信息就不应该放到版本控制库中。
  3. 应该总是通过自动化的过程将配置项从保存配置信息的存储库中取出并设置好，这样就能很容易地掌握不同环境中的配置信息了。
  4. 配置系统应该能依据应用、应用软件的版本、将要部署的环境，为打包、安装以及部署脚本提供不同的配置值。每个人都应该能够非常容易地看到当前软件的某个特定版本部署到各种环境上的具体配置信息。
  5. 对每个配置项都应用明确的命名习惯，避免使用晦涩难懂的名称，使其他人不需要说明手册就能明白这些配置项的含义。
  6. 确保配置信息是模块化且封闭的，使得对某处配置项的修改不会影响到那些与其无关的配置项。
  7. DRY（Don’t Repeat Yourself ）原则。定义好配置中的每个元素，使每个配置元素在整个系统中都是唯一的，其含义绝不与其他元素重叠。
  8. 最少化，即配置信息应尽可能简单且集中。除非有要求或必须使用，否则不要新增配置项。
  9. 避免对配置信息的过分设计，应尽可能简单。
  10. 确保测试已覆盖到部署或安装时的配置操作。检查应用程序所依赖的其他服务是否有效，使用冒烟测试来诊断依赖于配置项的相关功能是否都能正常工作。

    环境管理

    每个应用程序都依赖于硬件、软件、基础设施以及外部系统才能正常工作，我们把所有这些内容都称作应用程序的环境。

在做应用程序的环境管理时，我们需要记住的原则是：环境的配置和应用程序的配置同样重要。

环境管理的关键在于通过一个全自动过程来创建环境，使创建全新的环境总是要比修复已受损的旧环境容易得多。

对环境的变更过程进行管理是必要的，应该严格控制生产环境，未经组织内部正式的变更管理过程，任何人不得对其进行修改。这么做的原因很简单：即便很微小的变化也可能把环境破坏掉。任何变更在上线之前都必须经过测试，因而要将其编成脚本，放在版本控制系统中。这样，一旦该修改被认可，就可以通过自动化的方式将其放在生产环境中。

小结

配置管理是本书其他内容的基础。没有配置管理，根本谈不上持续集成、发布管理以及部署流水线。它对交付团队内部的协作也会起到巨大的促进作用。
我们希望读者清楚地认识到，这不只是选择和使用什么样工具的问题，尽管这非常重要，但更重要的是，如何正确地使用最佳实践。

如果配置管理流程比较好的话，对于下面的问题，你的回答都应该是肯定的：

  1. 是否仅依靠保存于版本控制系统中的数据（除了生产数据），就可以从无到有重建生产系统？
  2. 是否可以将应用程序回滚到以前某个正确的状态下？
  3. 是否能确保在测试、试运行和正式上线时以同样的方式创建部署环境？

如果回答是否定的，那么你的组织正处于风险之中。

我们建议为下面的内容制定出一个保存基线和控制变更的策略：

  1. 应用程序的源代码、构建脚本、测试、文档、需求、数据库脚本、代码库以及配置文件；
  2. 用于开发、测试和运维的工具集；
  3. 用于开发、测试和生产运行的所有环境；
  4. 与应用程序相关的整个软件栈，包括二进制代码及相关配置；
  5. 在应用程序的整个生产周期（包括构建、部署、测试以及运维）的任意一种环境上，与该应用程序相关联的配置。