发布工程哲学

发布工程师的日常工作是由下列4个主要的工程与服务哲学指导的。

自服务模型

为了应对大规模扩张，每个团队必须能够自给自足。发布工程师开发工具，制定最佳实践，以便让产品研发团队可以自己掌控和执行自己的发布流程。虽然我们有几千个工程师和几百个产品，Google仍然能够以很快的速度发布新产品。这是因为每一个团队都可以决定多久或者什么时候来发布产品的新版本。发布过程可以自动化到基本不需要工程师干预，很多项目都是利用我们的自动构建工具和部署工具自动构建、自动发布的。发布过程是真正的自动化的，工程师仅仅在发生问题时才会进行干预。

追求速度

面向用户的软件组件（例如Google搜索服务的很多组件）重新构建非常频繁，因为我们的目标是让用户可见的功能越快上线越好。我们同时也认为频繁的发布可以使得每个版本之间的变更减少。这种方式使得测试和调试变得更简单。有些团队每小时构建一次，然后在所有可用的构建版本中选择某个版本进行发布。选择过程是基于测试结果与所包含的功能列表共同得出的。还有的团队采用一种“测试通过即发布”（Push On Green）的发布模型，也就是说，部署每个通过所有测试的版本（参见文献[Kle14]）。

密闭性

构建工具必须确保一致性和可重复性。如果两个工程师试图在两台不同的机器上基于同一个源代码版本构建同一个产品，构建结果应该是相同的。[23]我们的构建过程都是密闭的（hermetic），意味着它们不受构建机器上安装的第三方类库或者其他软件工具所影响。构建过程使用指定版本的构建工具（编译器），同时使用指定版本的依赖库（第三方类库）。编译过程是自包含的，不依赖于编译环境之外的其他服务。

当修复某个运行在生产环境中的软件的Bug，而需要重新构建之前的一个发布版本时，一般来说是比较复杂的。Google按照之前的源代码版本，加入一些后来提交的改动来构建新的发布来解决这个问题，这种方式被称为摘樱桃（cherry picking）。构建工具自身也是放置在与被构建的程序同一个源代码仓库之中的。因此，如果要对上个月构建的某个项目进行cherry picking，仍然会用当时的编译器版本，而不会用到这个月新的编译器版本，这样可以保证编译器功能的一致性。

强调策略和流程

多层安全和访问控制机制可以确保在发布过程中只有指定的人才能执行指定的操作。我们主要关注的操作有如下几项：

● 批准源代码改动—通过源代码仓库中的配置文件决定。

● 指定发布流程中需要执行的具体动作。

● 创建新的发布版本。

● 批准初始的集成请求（也就是一个以某个源代码仓库版本为基础的构建请求），以及后续的cherry picking请求。

● 实际部署某个发布版本。

● 修改某个项目的构建配置文件。

几乎所有对源代码的修改都需要进行代码评审，这与我们日常开发工作流程是完美结合的。我们的自动化发布系统可以提供每个发布中包含的所有改动的报告，与其他的构建结果一起归档。SRE可以了解每个新发布中包含的具体改动，在发布出现问题时可以更快地进行在线调试。