配置管理

配置管理是发布工程师与SRE紧密合作的一个区域。虽然初看起来，配置管理可能很简单，但是这其实是不稳定性的一个重要来源。因此，我们的发布流程和系统运维与配置管理流程都随着时间不停地发展。今天我们使用下面几段描述的模型来分发配置文件。所有这些模型都需要将配置文件存放于我们的主要代码仓库中，同时进行严格的代码评审。

使用主分支版本配置文件。这是配置Borg服务的第一个方法（以及配置Borg之前的那些系统）。使用这个模型，开发者和SRE可以同时修改主分支上的配置文件。这些修改经过代码评审之后会应用到正在运行的系统上。这样做的结果是，二进制文件的发布与配置文件的修改是异步进行的。虽然理解起来和执行起来都比较容易，但这种方式经常会造成提交的版本和实际运行的配置文件不一致，因为任务必须要经过更新才能应用这些变更。

将配置文件与二进制文件打包在同一个MPM包中。对没有多少配置文件的项目来说，或者那些每次发布都会改变文件的项目来说，配置文件可以直接和二进制文件放在一个MPM包里。虽然这个策略在灵活性上有一定限制，但是简化了部署，仅仅需要安装一个包。

将配置文件打包成MPM配置文件包。我们也可以将密闭原则应用到配置管理上。二进制配置文件一般与某个二进制版本紧密相关，我们也可以利用编译系统和打包系统来发布配置文件。就像二进制文件那样，可以利用构建ID来重新构建某一时刻的配置文件。

例如，某个实现了新功能的变更可以与配置该功能的配置文件一起发布。通过打包两个MPM包，一个二进制文件，一个配置文件，可以对两个包进行单独修改。如果某个功能需要一个功能开关☆rst_folio，但是我们后面发现这个开关值应该为bad_quarto（这些是没有实际意义的名字），可以将这个变更cherry picking到发布分支上，重新构建配置包，再实际部署。这种方式可以避免再构建一次二进制文件。

我们可以利用MPM的标签功能选择哪些MPM包应该同时安装。much_ado这个标签可以应用到上面那段中的MPM包上，这样我们可以用一个标签同时获取两个版本。因为这些标签在每个MPM命名空间内部都是唯一的，只有最后一个包才能被用到。

从外部存储服务中读取配置文件。某些项目的配置文件需要经常改变，或者动态改变（在二进制文件运行时）。这些文件可以存放在Chubby、Bigtable或者Google自己的基于源代码仓库的文件系统中（参见文献[Kem11]）。

总之，项目负责人在分发和管理配置文件时有多种选择，可以按需决定究竟哪种最适合该服务。