讀書筆記（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）哪些釋出過程的名額比較有用？