第8章 發佈工程
發佈工程與產品研發部門的軟件工程師，以及SRE一起定義發佈軟件的過程的全部步驟——包括軟件是如何存儲於源代碼倉庫中，構建時如何進行測試，打包，最終部署的
發佈工程師角色
開發軟件，爲Google 提供各種數據（代碼修改提交部署到生產環境一共需要多長時間）。定義最佳實踐保障軟件項目可以一致的，可重複的進行發佈。
發佈工程哲學
- 自服務模型
- 每個團隊可以決定多久或者什麼時候來發布產品的新版本
- 發佈過程自動化，工程師僅僅在發生問題時纔會進行干預
- 追求速度
頻繁的發佈可以使每個版本之間的變更減少，這種方法使得測試和調試變得簡單
部署通過所有測試的版本（在所有可用的構建版本中選擇某個版本進行發佈）
- 密閉性
如果兩個工程師試圖在兩臺不同的機器上基於同一個源代碼版本構建同一個產品，構建結果應該是相同的。
- 強調策略和流程
- 幾乎所有對源代碼修改都需要進行代碼評審
- 自動化發佈系統可以提供每個發佈中包含的所有改動報告。與其他的構建結果一起歸檔
- SRE 可以瞭解每個發佈中包含的具體改動，在發佈問題時可以更改的進行在線調試
持續構建與部署
Rapid,Google自動化發佈系統，利用一系列Google 內部技術執行可擴展，密閉性，以及可靠的發佈流程
- 構建
- Blaze , Google 的構建工具，定義構建輸出結構，如jar 文件，同時給每個目標的依賴關係。
- 可以顯示自身構建時間，構建源代碼版本，構建標識符，可以將輸出結果與構建過程對應起來
- 分支
- 提交代碼到主分支上，在副分支上發佈版本。
- 提交Bug 到主分支，Cherry picking 到發佈分支
- 測試
- 在每個主分支改動提交後運行單元測試（快速檢測構建錯誤，測試錯誤）
- 發佈過程中，使用使用發佈分支運行所有的單元測試，發佈分支可能包含主分支上不存在的代碼版本
- 使用獨立測試環境來打包好的構建結果運行一些系統級別的測試
- 打包
- 軟件通過Midea Package Manager(MPM)系統分發到生產機器上。
- MPM 基於Blaze 規則中列出的構建結果和權限結果構建MPM包。
- 每個包有固定名稱，記錄構建結果的哈希值，加入簽名以確保真實完整性
- Rapid 系統
![Rapid 系統結構（簡化）]()
由Blueprint配置語言寫成的配置文件。定義構建目標，測試目標，部署規則以及一些管理用信息
典型的發佈流程按如下進行
- Rapid 使用集成版本號（通常從持續測試系統獲得）創建新的發佈分支
- Rapid利用Balze編譯所有二進制文件，同時執行所有單元測試，兩個過程通常併發進行。編譯和測試各自在獨立的環境中運行，而非Rapid工作流運行環境中，隔離使得併發更容易一些。
- 構建結果隨後可以用來運行系統級集成測試，同時進行測試部署。典型的測試部署過程在系統測試完成之後，在生產環境中啓動一系列Borg 任務
- 每一步的記過都有日誌記錄，另外產生一份與上次發佈對比包含所有新的改動列表的報告
Rapid 可以管理髮布分支與cheery picking. 每個具體的cheery picking 請求可以被單獨批准和拒絕
- 部署
- Rapid 經常可以直接驅動簡單的部署流程
- Sisyphus ,SRE 開發的一個通用的發佈自動化框架，執行復雜的部署任務。
- Repid 在某個Sisyphus系統中創建一個新的發佈，Rapid知道自己構建的MPM包的build標籤，Sisphus 可以利用這個build 標籤指定究竟使用那個MMP 版本進行部署。
- 配置管理
分發配置文件的模型
- 主分支版本配置文件
1.1 開發者和SRE同時修改主分支上的配置文件，經過代碼評審後應用到正在運行的系統上。可能會造成提交版本和實際運行配置文件不一致，任務必須要經過更新才能應用這些變更。- 將配置文件與二進制文件打包在同一個MPM包中
2.1 配置文件與二進制文件放在一個MPM 包中，雖然策略有一定限制，但是簡化部署- 將配置文件打包成MPM配置文件包
3.1 一個二進制文件，一個配置文件，可以單獨修改- 從外部存儲服務中讀取配置文件