SRE Google运维解密——第8章 发布工程

第8章 发布工程

发布工程与产品研发部门的软件工程师，以及SRE一起定义发布软件的过程的全部步骤——包括软件是如何存储于源代码仓库中，构建时如何进行测试，打包，最终部署的

---

发布工程师角色

开发软件，为Google 提供各种数据（代码修改提交部署到生产环境一共需要多长时间）。定义最佳实践保障软件项目可以一致的，可重复的进行发布。

发布工程哲学

• 自服务模型

• 每个团队可以决定多久或者什么时候来发布产品的新版本
• 发布过程自动化，工程师仅仅在发生问题时才会进行干预

• 追求速度
  频繁的发布可以使每个版本之间的变更减少，这种方法使得测试和调试变得简单

部署通过所有测试的版本（在所有可用的构建版本中选择某个版本进行发布）

• 密闭性

如果两个工程师试图在两台不同的机器上基于同一个源代码版本构建同一个产品，构建结果应该是相同的。

• 强调策略和流程

• 几乎所有对源代码修改都需要进行代码评审
• 自动化发布系统可以提供每个发布中包含的所有改动报告。与其他的构建结果一起归档
• SRE 可以了解每个发布中包含的具体改动，在发布问题时可以更改的进行在线调试

持续构建与部署

Rapid,Google自动化发布系统，利用一系列Google 内部技术执行可扩展，密闭性，以及可靠的发布流程

• 构建

• Blaze , Google 的构建工具，定义构建输出结构，如jar 文件，同时给每个目标的依赖关系。
• 可以显示自身构建时间，构建源代码版本，构建标识符，可以将输出结果与构建过程对应起来

• 分支

• 提交代码到主分支上，在副分支上发布版本。
• 提交Bug 到主分支，Cherry picking 到发布分支

• 测试

• 在每个主分支改动提交后运行单元测试（快速检测构建错误，测试错误）
• 发布过程中，使用使用发布分支运行所有的单元测试，发布分支可能包含主分支上不存在的代码版本
• 使用独立测试环境来打包好的构建结果运行一些系统级别的测试

• 打包

• 软件通过Midea Package Manager(MPM)系统分发到生产机器上。
• MPM 基于Blaze 规则中列出的构建结果和权限结果构建MPM包。
• 每个包有固定名称，记录构建结果的哈希值，加入签名以确保真实完整性

• Rapid 系统
  

由Blueprint配置语言写成的配置文件。定义构建目标，测试目标，部署规则以及一些管理用信息

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

1. Rapid 使用集成版本号（通常从持续测试系统获得）创建新的发布分支
2. Rapid利用Balze编译所有二进制文件，同时执行所有单元测试，两个过程通常并发进行。编译和测试各自在独立的环境中运行，而非Rapid工作流运行环境中，隔离使得并发更容易一些。
3. 构建结果随后可以用来运行系统级集成测试，同时进行测试部署。典型的测试部署过程在系统测试完成之后，在生产环境中启动一系列Borg 任务
4. 每一步的记过都有日志记录，另外产生一份与上次发布对比包含所有新的改动列表的报告
   Rapid 可以管理发布分支与cheery picking. 每个具体的cheery picking 请求可以被单独批准和拒绝

• 部署

• Rapid 经常可以直接驱动简单的部署流程
• Sisyphus ,SRE 开发的一个通用的发布自动化框架，执行复杂的部署任务。
• Repid 在某个Sisyphus系统中创建一个新的发布，Rapid知道自己构建的MPM包的build标签，Sisphus 可以利用这个build 标签指定究竟使用那个MMP 版本进行部署。

• 配置管理
  分发配置文件的模型

1. 主分支版本配置文件
   1.1 开发者和SRE同时修改主分支上的配置文件，经过代码评审后应用到正在运行的系统上。可能会造成提交版本和实际运行配置文件不一致，任务必须要经过更新才能应用这些变更。
2. 将配置文件与二进制文件打包在同一个MPM包中
   2.1 配置文件与二进制文件放在一个MPM 包中，虽然策略有一定限制，但是简化部署
3. 将配置文件打包成MPM配置文件包
   3.1 一个二进制文件，一个配置文件，可以单独修改
4. 从外部存储服务中读取配置文件