使用 GitLab/GitHub/Gerrit + Zadig 實現主幹開發主幹釋出（含位元組飛書實踐）

語言: CN / TW / HK
時間 2022-05-26 12:01:14
一個完整的產品交付過程涉及到分支策略、團隊的協作流程、基礎設施建設等方方面面，有些團隊交付效率之所以低下，往往是因為其中的某個環節出了短板，高效的協作需要結合 專案所處的階段、 產品交付的頻率、 團隊成員的習慣和素養等來制定適合自己團隊的方案。
在團隊日常協作過程中，選擇一個合適的分支策略尤為重要，在此基礎上團隊角色之間的協作過程才可以被定義和執行，生產過程才能高效運轉，從而產品功能才可高質量交付。
主流的分支策略有：
  • 主幹開發，主幹釋出
  • 主幹開發，分支釋出
  • 分支開發，主幹釋出
  • GitFlow
  • ...
本文主要介紹“主幹開發、主幹釋出”分支策略在 Zadig 上的實踐過程。以下實踐過程主要以 Gerrit 程式碼源為例，其他型別程式碼源比如 GitLab、GitHub、Gitee 同樣適用。
 
 

什麼是主幹開發、主幹釋出

開發程式碼直接提交到主幹分支，經過測試驗證後，使用主幹分支進行打版上線。
 
優勢：
  • 分支管理簡單
  • 開發易上手，操作簡單，不易出錯
  • 程式碼合併衝突少
  • 適合高頻交付 
成功關鍵點：
  • 主幹分支時刻保持可釋出的狀態，開發自測階段/CR 過程/主幹分支驗證過程需要嚴格把控
  • 未開發完成的功能程式碼，不能帶入將要釋出的版本里或者實現功能開關，將未完成的功能隱藏
 

團隊協作流程詳解

本地開發&自測 -> 提交 Pull Request 到 主幹分支（main） -> 程式碼審查 & 合併程式碼 -> 手動驗證功能/補充自動化測試用例 -> 基於 主幹分支交付版本
團隊協作流程
 
團隊協分工
 
 

飛書基於 Zadig 的實踐過程

早期飛書的使用場景，其中一個團隊有上百個微服務，服務定義使用原生的 K8s YAML 方式，使用 Gerrit 作為程式碼管理和人工稽核工具來實現主幹開發主幹釋出。具體過程如下：
 
  1. 提交程式碼變更：修改程式碼，提交 MR ，生成 change-id
  2. 人工審查：新增/通知程式碼審查人；審查人可以多次 submit 審查，通過一個 transection 提交，通過審查，可以打分 -2 到 2；
  3. 機器審查：非阻塞式自動觸發 Zadig 工作流執行驗證：構建->部署->測試；
  4. 主幹反饋：工作流跑完後會傳送 IM 通知，並執行 Gerrit 打分校驗結果 score +1-1
系統可以配置審查規則，比如達到 2 分自動合併，自動化測試比較多的情況可以這樣。
  1. 基於主幹釋出上線
上述 過程 3 依賴測試環境，容易造成環境資源的浪費和審查過程等待的情況，飛書團隊選擇使用 Zadig Webhook 動態分配空閒環境 的能力，既可以合理利用環境資源又不阻塞機器審查過程。
服務配置提取出不同的環境變數來 區分整合環境 ，根據人員的配置情況，建立 4 個同構環境，日常開發只需要提交程式碼並建立 Gerrit change，自動觸發工作流做程式碼的構建部署和自動化測試。
  1. 開發 A 提交一個更新 service-a 的 PR1，自動觸發 Zadig 工作流 -> 構建 service-a ->更新 ENV1 的 service-a -> 針對 ENV1 執行測試指令碼
  2. 開發 B 提交一個更新 service-b 的 PR2，自動觸發 Zadig 工作流 -> 構建 service-b ->更新 ENV2 的 service-b -> 針對 ENV2 執行測試指令碼
  3. PR1、PR2 合併 Master 後分別觸發工作流 -> 構建 service-a、構建 service-b -> 更新所有的環境，保證所有環境和主幹一致。

動態分配空閒環境實踐

 

 
飛書後續採用 GitLab 管理程式碼，關於 GitLab 的分支模型和更多實踐可參考文件： 位元組跳動飛書為什麼選擇 Zadig 實現主幹開發、主幹釋出 | 部落格。

 

Demo 演示實踐

  1. 專案基本搭建過程

  1. 更多配置

    1. 按需建立多個環境，具體參考 配置多套環境 | Zadig 文件
    2. 工作流配置 Webhook 觸發器：環境的負載均衡 | Zadig 文件
    3. 工作流配置 IM 通知：工作流 | Zadig 文件
    4. 多個服務共享構建：構建 | Zadig 文件

日常研發使用過程

開發工程師

  1. 程式碼提交併自動驗證：提交程式碼 -> 在 Gerrit 上建立 Change -> 自動觸發 Zadig 工作流的執行（構建 -> 動態選擇空閒環境進行部署 -> 自動化測試 ）

 
  1. 人工程式碼審查：Reviewer 使用 Gerrit 作為程式碼審查工具並打分，根據打分結果來判斷程式碼是否可以合併
系統可以配置 rules，比如達到 2 分自動合併

測試開發工程師

  1. 在 Zadig 上配置管理測試指令碼： 測試 | Zadig 文件
  2. 針對更新後的環境驗證新功能，為新功能補充測試用例

釋出工程師

  1. 基於主幹已驗證的程式碼進行版本釋出
  2. 釋出完成後執行工作流將所有環境中的服務版本與主幹保持一致

專案/企業管理人員

檢視企業專案整體的執行狀況： 資料概覽 | Zadig 文件
分析專案各個環節的變化過程以及效能短板： 效能洞察 | Zadig 文件
 
後續將推出更多分支策略以及團隊協作流程相關實踐專題文章，敬請期待...
 
Zadig，讓工程師更專注創造！歡迎加入 開源吐槽群🔥
 
 
 
 
「」
「」