图 8-1展示了Rapid系统中的主要组件。Rapid是用Bhueprin文件配置的。Blueprint文件是一种利用Google内部配置语言写成的，用来定义构建目标和测试目标、部署规则，以及一些管理用信息（例如项目负责人信息）。基于角色的访问控制列表可以决定谁能执行哪些动作。

每个Rapid项目都有一些工作流，定义了发布流程中的具体动作。工作流可以线性或者并发执行，某个工作流也可以启动另外一个工作流。Rapid将工作请求分发给运行在Borg系统上的生产服务器。因为Rapid使用Google的生产基础设施，我们可以同时处理几千个发布请求。

典型的发布流程按如下顺序进行∶

1.Rapid使用集成版本号（通常自动从持续测试系统获取）创建新的发布分支。

2.Rapid利用Blaze编译所有的二进制文件，同时执行所有的单元测试，这两个过程通常是并发进行的。编译和测试各自在独立的环境中进行，而非Rapid工作流运行的环境中。这种隔离使得并发更容易一些。

3.构建结果随后可以用来运行系统级集成测试，同时进行测试部署。典型的测试部署过程是在系统测试完成之后，在生产环境中启动一系列Borg 任务。

4.每一步的结果都有日志记录。另外产生一份与上次发布对比包含的所有新的改动列表的报告。

Rapid可以管理发布分支与cheery picking。每个具体的cherrypicking 请求可以被单独批准和拒绝。

部署

Rapid经常被用来直接驱动简单的部署流程。它可以根据 Blueprint文件定义的部署规则，利用具体的任务执行器（executor）来用新构建的MPM包更新Borg任务。

我们使用 Sisyphus，SRE开发的一个通用的发布自动化框架，来执行更为复杂的部署任务。一个发布（rollout）是由一个或多个任务组成的一个逻辑工作单元。Sisyphus 提供了一系列可扩展的Python类，以支持任意部署流程。同时，它还有一个监控台，可以用来详细控制每个发布的执行，以及监控发布流程。

在典型的集成流程中，Rapid在某个Sisyphus系统中创建一个新的发布。Rapid知道自己构建的MPM包的 build标签，可以在创建发布时指定这个标签。Sisyphus可以利用这个 build 标签来指定究竟使用哪个 MPM版本进行部署。

Sisyphus，可以支持简单的发布流程，也可以支持复杂的发布流程。例如，我们可以立即更新所有的相关任务，也可以在几个小时的周期内，一个接一个地更新集群版本。

我们的目标是让部署流程与服务的风险承受能力相结合。在开发环境或者预生产环境中，我们可能会每小时构建一次，同时在所有测试通过之后自动发布更新。对于大型面向用户的服务来说，我们可能会先更新一个集群，再以指数速度更新其他集群直到全部完成。对敏感的基础设施服务来说，我们可能会将发布扩展到几天内完成，根据这些实例所在的地理位置交替进行。

图 8-1展示了Rapid系统中的主要组件。Rapid是用Bhueprin文件配置的。Blueprint文件是一种利用Google内部配置语言写成的，用来定义构建目标和测试目标、部署规则，以及一些管理用信息（例如项目负责人信息）。基于角色的访问控制列表可以决定谁能执行哪些动作。

每个Rapid项目都有一些工作流，定义了发布流程中的具体动作。工作流可以线性或者并发执行，某个工作流也可以启动另外一个工作流。Rapid将工作请求分发给运行在Borg系统上的生产服务器。因为Rapid使用Google的生产基础设施，我们可以同时处理几千个发布请求。

典型的发布流程按如下顺序进行∶

1.Rapid使用集成版本号（通常自动从持续测试系统获取）创建新的发布分支。

2.Rapid利用Blaze编译所有的二进制文件，同时执行所有的单元测试，这两个过程通常是并发进行的。编译和测试各自在独立的环境中进行，而非Rapid工作流运行的环境中。这种隔离使得并发更容易一些。

3.构建结果随后可以用来运行系统级集成测试，同时进行测试部署。典型的测试部署过程是在系统测试完成之后，在生产环境中启动一系列Borg 任务。

4.每一步的结果都有日志记录。另外产生一份与上次发布对比包含的所有新的改动列表的报告。

Rapid可以管理发布分支与cheery picking。每个具体的cherrypicking 请求可以被单独批准和拒绝。

部署

Rapid经常被用来直接驱动简单的部署流程。它可以根据 Blueprint文件定义的部署规则，利用具体的任务执行器（executor）来用新构建的MPM包更新Borg任务。

我们使用 Sisyphus，SRE开发的一个通用的发布自动化框架，来执行更为复杂的部署任务。一个发布（rollout）是由一个或多个任务组成的一个逻辑工作单元。Sisyphus 提供了一系列可扩展的Python类，以支持任意部署流程。同时，它还有一个监控台，可以用来详细控制每个发布的执行，以及监控发布流程。

在典型的集成流程中，Rapid在某个Sisyphus系统中创建一个新的发布。Rapid知道自己构建的MPM包的 build标签，可以在创建发布时指定这个标签。Sisyphus可以利用这个 build 标签来指定究竟使用哪个 MPM版本进行部署。

Sisyphus，可以支持简单的发布流程，也可以支持复杂的发布流程。例如，我们可以立即更新所有的相关任务，也可以在几个小时的周期内，一个接一个地更新集群版本。

我们的目标是让部署流程与服务的风险承受能力相结合。在开发环境或者预生产环境中，我们可能会每小时构建一次，同时在所有测试通过之后自动发布更新。对于大型面向用户的服务来说，我们可能会先更新一个集群，再以指数速度更新其他集群直到全部完成。对敏感的基础设施服务来说，我们可能会将发布扩展到几天内完成，根据这些实例所在的地理位置交替进行。