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

阿新 • • 發佈：2018-12-18

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

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 過程包含了

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

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

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

該流程保證了

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

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

持續釋出的優點

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

如下圖所示，基於單分支的 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

注：

在 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

生產環境中發現 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

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