读书笔记（SRE：Google运维解密）：第8章 发布工程

• 发布工程师通常对源代码管理、编译器、构建配置语言、自动化构建工具、包管理器和安装器等非常了解（甚至是这方面的专家）。
  技能横跨很多领域：开发、配置管理、测试集成、系统管理，甚至用户支持。
   
• 发布工程哲学：
  （a）自服务模型：发布过程是真正的自动化的，工程师仅仅在发生问题时才会进行干预。
  （b）追求速度：“测试通过即发布”（Push OnGreen）发布模型
  （c）密闭性：构建过程都是密闭的（hermetic），意味着它们不受构建机器上安装的第三方类库或者其他软件工具所影响。构建过程使用指定版本的构建工具（编译器），同时使用指定版本的依赖库（第三方类库）。编译过程是自包含的，不依赖于编译环境之外的其他服务
  （d）强调策略和流程：多层安全和访问控制机制可以确保在发布过程中只有指定的人才能执行指定的操作。主要关注的操作有如下几项：
  • 批准源代码改动—通过源代码仓库中的配置文件决定。
  • 指定发布流程中需要执行的具体动作。
  • 创建新的发布版本。
  • 批准初始的集成请求（也就是一个以某个源代码仓库版本为基础的构建请求），以及后续的cherry picking请求。
  • 实际部署某个发布版本。
  • 修改某个项目的构建配置文件。
     
• 持续构建与交付
  （a）构建：定义构建目标，即构建的输出结果，同时给每个目标指定依赖关系。当进行具体构建时，自动构建目标的全部依赖
  （b）分支：所有的代码都默认提交到主分支上（mainline）。然而，大部分的项目都不会直接从主分支上进行直接发布。我们会基于主分支的某一个版本创建新分支，新分支的内容永远不会再合并入主分支。Bug修复先提交到主分支，再cherry picking到发布分支上。这种方式可以避免在第一次构建之后，再引入主分支上的其他的无关改动。利用这种分支与cherry picking的方法，可以明确每个发布版本中包含的全部改动。这块有点意思
  （c）测试：一个持续测试系统会在每个主分支改动提交之后运行单元测试，这样可以快速检测构建错误和测试错误。
  （d）打包：构建MPM（Midas Package Manager）包，加标签
  （e）部署：利用build标签来指定究竟使用哪个MPM版本进行部署。
   
• Google 自动化发布系统：Rapid
  

典型的发布流程按如下顺序进行：
（a）Rapid使用集成版本号（通常自动从持续测试系统获取）创建新的发布分支。
（b）Rapid利用Blaze编译所有的二进制文件，同时执行所有的单元测试，这两个过程通常是并发进行的。编译和测试各自在独立的环境中进行，而非Rapid工作流运行的环境中。这种隔离使得并发更容易一些。
（c）构建结果随后可以用来运行系统级集成测试，同时进行测试部署。典型的测试部署过程是在系统测试完成之后，在生产环境中启动一系列Borg任务。
（d）每一步的结果都有日志记录。另外产生一份与上次发布对比包含的所有新的改动列表的报告。

• 每个Rapid项目都有一些工作流，定义了发布流程中的具体动作。工作流可以线性或者并发执行，某个工作流也可以启动另外一个工作流。Rapid将工作请求分发给运行在Borg系统上的生产服务器。因为Rapid使用Google的生产基础设施，我们可以同时处理几千个发布请求。
• Blaze是Google的构建工具，它支持多种编程语言，如Google内部标准的 C++、Java、Python、Go 以及JavaScript。

 

• 几种配置管理模型：
  （a）主分支版本配置文件：二进制文件的发布与配置文件的修改是异步进行的
  （b）将配置文件与二进制文件打包在同一个MPM包中：对没有多少配置文件的项目来说，或者那些每次发布都会改变文件的项目来说，简化了部署
  （c）将配置文件打包成MPM配置文件包
  （d）从外部存储服务中读取配置文件：适用于配置文件需要经常改变，或者动态改变（在二进制文件运行时）
   
• 发布工程问题：
  （a）如何管理包的版本？
  （b）应该采用持续构建和部署的模型，还是应该定期构建？
  （c）发布的频率应该怎样？
  （d）应该使用什么策略管理配置文件？
  （e）哪些发布过程的指标比较有用？