Spark 灰度釋出在十萬級節點上的成功實踐 CI CD

郭俊JasonGuo發表於2018-10-31

Spark

原創文章，轉載請務必將下面這段話置於文章開頭處。
本文轉發自技術世界，原文連結　 http://www.jasongj.com/spark/ci_cd/

本文所述內容基於某頂級網際網路公司數萬節點下 Spark 的 CI 與 CD & CD 實踐。為了提高本文內容的可借鑑性，隱去了公司特有內容，只保留通用部分

Spark CI 持續整合實踐

CI 介紹

持續整合是指，及時地將最新開發的且經過測試的程式碼整合到主幹分支中。
Continuous Integration

持續整合的優點

快速發現錯誤 每次更新都及時整合到主幹分支中，並進行測試，可以快速發現錯誤，方便定位錯誤
避免子分支大幅偏離主幹分支 主幹在不斷更新，如果不經常整合，會產生後期整合難度變大，甚至難以整合，並造成不同開發人員間不必要的重複開發
為快速迭代提供保障 持續整合為後文介紹的持續釋出與持續部署提供了保證

Spark CI 實踐

目前主流的程式碼管理工具有，Github、Gitlab等。本文所介紹的內容中，所有程式碼均託管於私有的 Gitlab 中。

鑑於 Jenkins 幾乎是 CI 事實上的標準，本文介紹的 Spark CI CD & CD 實踐均基於 Jenkins 與 Gitlab。

Spark 原始碼儲存在 spark-src.git 庫中。

由於已有部署系統支援 Git，因此可將整合後的 distribution 儲存到 Gitlab 的釋出庫（spark-bin.git）中。

每次開發人員提交程式碼後，均通過 Gitlab 發起一個 Merge Requet （相當於 Gitlab 的 Pull Request）

每當有 MR 被建立，或者被更新，Gitlab 通過 Webhook 通知 Jenkins 基於該 MR 最新程式碼進行 build。該 build 過程包含了

編譯 Spark 所有 module
執行 Spark 所有單元測試
執行效能測試
檢查測試結果。如果有任意測試用例失敗，或者效能測試結果明顯差於上一次測試，則 Jenkins 構建失敗

Jenkins 將 build 結果通知 Gitlab，只有 Jenkins 構建成功，Gitlab 的 MR 頁面才允許 Merge。否則 Gitlab 不允許 Merge

另外，還需人工進行 Code Review。只有兩個以上的 Reviewer 通過，才能進行最終 Merge

所有測試與 Reivew 通過後，通過 Gitlab Merge 功能自動將程式碼 Fast forward Merge 到目標分支中

該流程保證了

所有合併進目標分支中的程式碼都經過了單元測試（白盒測試）與效能測試（黑盒測試）
每次發起 MR 後都會及時自動發起測試，方便及時發現問題
所有程式碼更新都能及時合併進目標分支

Spark CD 持續交付

CD 持續交付介紹

持續交付是指，及時地將軟體的新版本，交付給質量保障團隊或者使用者，以供評審。持續交付可看作是持續整合的下一步。它強調的是，不管怎麼更新，軟體都是可隨時交付的。

這一階段的評審，一般是將上文整合後的軟體部署到儘可能貼近生產環境的 Staging 環境中，並使用貼近真實場景的用法（或者流量）進行測試。
Continuous Delivery

持續釋出的優點

快速釋出 有了持續整合與持續釋出，可快速將最新功能釋出出來，也可快速修復已知 bug
快速迭代 由於釋出及時，可以快速判斷產品是否符合產品經理的預期或者是否能滿足使用者的需求

Spark CD 持續釋出實踐

這裡有提供三種方案，供讀者參考。推薦方案三

方案一：單分支

正常流程

如下圖所示，基於單分支的 Spark 持續交付方案如下

所有開發都在 spark-src.git/dev（即 spark-src.git 的 dev branch）上進行
每週一將當前最新程式碼打包，放進 spark-bin.git/dev 的 spark-${ build # }（如圖中第 2 周的 spark-72）資料夾內
spark-prod 指向當前 spark-dev 指向的資料夾（如圖中的 spark-71 ）
spark-dev 指向 spark-${ build # }（如圖中的 spark-72）
自動將 spark-bin.git 最新內容上線到 Staging 環境，並使用 spark-dev 進行測試
spark-prod 比 spark-dev 晚一週（一個 release 週期），這一週用於 Staging 環境中測試

Continuous Delivery Solution 1

注：

藍色圓形是正常 commit
垂直虛線是釋出時間點，week 1、week 2、week 3、week 4
最上方黑色粗橫線是原始碼時間線
下方黃色粗橫線是 release 時間線
綠色方框是每週生成的 release，帶 build #
藍色方框是開發版本的 symbolic
橘色方框是線上版本的 symbolic

bug fix

在 Staging 環境中發現 spark-dev 的 bug 時，修復及整合和交付方案如下

如果在 Staging 環境中發現了 spark-dev 的 bug，且必須要修復（如不修復，會帶到下次的 spark-prod 的 release 中），則提交一個 commit，並且 commit message 包含 bugfix 字樣（如圖中黑色圓形 commit 9 所示）
該 bugfix 被 Merge 後，Jenkins 得到通知
Jenkins 發現該 commit 是 bugfix，立即啟動構建，生成spark-${ build \# }（如圖中的 spark-73）
spark-dev 指向 spark-${ build \# } （如圖中的 spark-73 ）

Continuous Delivery Solution 1 bug fix

hot fix

生產環境中發現 bug 時修復及交付方案如下

如果發現線上版本（即 spark-prod）有問題，須及時修復，則提交一個 commit，並且 commit message 包含 hotfix 字樣（如圖中紅色圓形 commit 9 所示）
該 hotfix 被 Merge 後，Jenkins 得到通知
Jenkins 發現該 commit 是 hotfix，立即啟動構建，生成 spark-${ build \# }（如圖中的 spark-73）
spark-dev 與 spark-prod 均指向 spark-${ build \# } （如圖中的 spark-73 ）

Continuous Delivery Solution 1 hotfix

Pros.

spark-src.git 與 spark-bin.git 都只有一個分支，維護方便
spark-prod 落後於 spark-dev 一週（一個 release），意味著 spark-prod 都成功通過了一週的 Staging 環境測試

Cons.

使用 spark-prod 與 spark-dev 兩個 symbolic，如果要做灰度釋出，需要使用者修改相應路徑，成本較高
hotfix 時，引入了過去一週多（最多兩週）未經 Staging 環境中通過 spark-dev 測試的 commit，增加了不確定性，也違背了所有非 hotfix commit 都經過了一個釋出週期測試的原則