譯者 | 劉汪洋
審校 | 重樓
開始構(gòu)建發(fā)布流水線
GreptimeDB 自開源伊始，就采用 GitHub Actions 實現(xiàn)了自動化軟件構(gòu)建過程，從而誕生了首個發(fā)布流水線。
對于開源項目，構(gòu)建一個穩(wěn)定且一致的發(fā)布流水線具有以下關(guān)鍵價值：
- 供應(yīng)隨時可用的軟件構(gòu)件：身為軟件供應(yīng)鏈的上游生產(chǎn)者，我們必須為不同的下游用戶提供安全、可信賴、隨時可用的軟件構(gòu)件，如二進(jìn)制文件、鏡像等。
- 優(yōu)化開發(fā)者體驗：用戶可無需繁瑣配置或從零開始設(shè)置和編譯，即可獲取適合各自平臺的即時可執(zhí)行的軟件構(gòu)件。
- 實現(xiàn)發(fā)布工作流的自動化測試：結(jié)合不同類型的回歸測試（例如性能、穩(wěn)定性、集成測試等）和自動發(fā)布流程，以提高軟件的整體質(zhì)量。
雖有其他替代方案，如 Circle CI、Travis CI、GitLab CI，或自托管的開源項目如 Tekton 和 Argo Workflow， 但選擇 GitHub Actions 的理由顯而易見：它與 GitHub 生態(tài)系統(tǒng)融合，為用戶提供了便捷的操作界面和豐富的軟件市場訪問權(quán)限。
然而，用戶友好并不意味著維護(hù)輕松。相反，GitHub Actions 的維護(hù)可能變得復(fù)雜。GreptimeDB 的最初開源版本中的 release.yml 僅包含了精煉的183行代碼。但隨著許多貢獻(xiàn)者的修改，這份文件逐漸演變并整合了：
- 構(gòu)建多樣化平臺上的構(gòu)件；
- 構(gòu)建激活軟件構(gòu)件的不同功能開關(guān)；
- 在實際構(gòu)建之前執(zhí)行集成測試；
- 將軟件構(gòu)件推送到不同倉庫（如 DockerHub、ACR、S3等）；
- 控制不同的發(fā)布條件（如手動觸發(fā)、錯誤容限等）；
- 等等。
還有，由于一些特殊需求（如調(diào)試發(fā)布、每日構(gòu)建等），在不同的內(nèi)部倉庫中產(chǎn)生了許多只有微小差異的相似流水線分支，這增加了維護(hù)的壓力。
隨著構(gòu)建要求的復(fù)雜性不斷提高，release.yml 文件迅速變得龐大，充滿了冗余配置，維護(hù)難度增大。如果不及時進(jìn)行重構(gòu)，發(fā)布流水線將面臨迅速甚至徹底的失效風(fēng)險。
發(fā)布流水線退化問題分析
隨著構(gòu)建要求的復(fù)雜性不斷提高，release.yml 文件迅速變得龐大，充滿了冗余配置，維護(hù)難度增大。如果不及時進(jìn)行重構(gòu)，發(fā)布流水線將面臨迅速甚至徹底的失效風(fēng)險。
發(fā)布流水線退化問題分析
審查release.yml文件后，我們需要識別一些促使它迅速退化的因素。只有深入了解問題的根源，我們才能制定合適的重構(gòu)方案。
- 語言局限性：GitHub Actions 的基于 YAML 的領(lǐng)域特定語言（DSL）與通用編程語言相比表現(xiàn)力不足，從而可能產(chǎn)生冗余和難以維護(hù)的代碼。
- 調(diào)試難度高：GitHub Actions 因難以調(diào)試而聞名，特別是項目使用的 Rust 語言編譯成本較高，進(jìn)一步加長了調(diào)試周期。盡管如 act 等工具可以在本地執(zhí)行 GitHub Actions，但實際運行操作仍然必須進(jìn)行，因此無法有效縮短編寫-運行-調(diào)試的周期。
- 動作解耦不足：GitHub Actions 通過 Composite 組合不同動作。我們由于缺乏經(jīng)驗，未將邏輯分解為獨立動作，而是將所有內(nèi)容集中到一個 YAML 文件中，因此維護(hù)起來較為困難。
- 重復(fù)構(gòu)建問題：由于 GitHub 缺乏支持 ARM64 的虛擬機實例，為了優(yōu)化編譯性能，我們選擇在 GitHub 的 x86_64 虛擬機實例上進(jìn)行 AMD64 和 ARM64 軟件構(gòu)件的跨平臺編譯。雖然可以使用 Docker Buildx 激活 QEMU 進(jìn)行 ARM64 平臺模擬構(gòu)建，但性能不佳。由于我們依賴于 GitHub Runner 主機環(huán)境而非 Dockerfile，實現(xiàn)一致的可重復(fù)構(gòu)建頗具挑戰(zhàn)性。
能夠在首次嘗試時就成功執(zhí)行 GitHub Actions 的人非常罕見。
我們在重構(gòu)過程的開始階段，應(yīng)該首先注重可維護(hù)性優(yōu)于性能（構(gòu)建速度）。發(fā)布的流水線將隨項目的增長不斷演化，因此可維護(hù)性至關(guān)重要。如果忽視了可維護(hù)性，可能會逐漸陷入困境，最終導(dǎo)致研發(fā)效率的降低。只有保障了可維護(hù)性，我們才能著手提高性能。在編譯/構(gòu)建場景中，合理利用各種緩存機制和優(yōu)質(zhì)的構(gòu)建機器通常能夠提升性能。
重構(gòu)計劃
重構(gòu) YAML 文件不同于常規(guī)編程項目，它更多地是一次對配置流程的全面審查，雖然這聽起來并不完全符合邏輯，卻存在較高的偶發(fā)復(fù)雜性。在此過程中容易陷入難以察覺的問題，進(jìn)而可能面臨解決的艱難挑戰(zhàn)。以下總結(jié)了針對正在經(jīng)歷此類重構(gòu)的一些實用建議。
- 采用 Dockerfile 實現(xiàn)構(gòu)建標(biāo)準(zhǔn)化：雖然基于 Dockerfile 的構(gòu)建可能影響性能，但這樣的方式增強了可維護(hù)性，統(tǒng)一了跨平臺構(gòu)建流程，確保了構(gòu)建的可重復(fù)性。
- 統(tǒng)一構(gòu)建命令接口：基于上述考慮，需將各類構(gòu)建命令精簡為單一 make 命令。將編譯的復(fù)雜性限制在 yaml 文件之外，避免發(fā)布階段隱藏過多細(xì)節(jié)，且在開發(fā)階段的 Makefile 或腳本中展現(xiàn)出來。通過 Makefile，用戶可以體驗到與發(fā)布階段一致的構(gòu)建過程，從而提升開發(fā)效率。
- 采用 AWS EC2：鑒于 GitHub Actions 目前缺乏 ARM64 VM 實例，需要采用交叉編譯。使用 AWS EC2 ARM64 實例來構(gòu)建 ARM64 平臺的軟件，以實現(xiàn)所有平臺構(gòu)建過程的標(biāo)準(zhǔn)化。
- 模塊化解耦合：將 release.yml 拆分，使其成為一組明了的任務(wù)集合。每個位于 actions 目錄下的 action.yml 文件都應(yīng)保持簡潔明了，以便根據(jù)相同操作自定義各種流程，提高整個過程的靈活性和效率。由于 GitHub Actions 內(nèi)無組任務(wù)機制，此法是最佳方案。
- 簡化任務(wù)執(zhí)行：每個任務(wù)需專注于單一、特定的任務(wù)，增強其冪等性。這樣在出錯時，重試工作將更容易。此外，有助于更有效地提取頂層控制變量，允許更精確的手動觸發(fā)控制。
- 避免在 Actions 中過度加載 Shell 命令：不要在單個 GitHub Actions 步驟中打包過多 Shell 命令，以利于維護(hù)。如果命令較多，可考慮轉(zhuǎn)換為外部腳本并精簡輸入?yún)?shù)，確保腳本的獨立執(zhí)行和驗證。
- 引入 Pre Job 分配 Runners：Allocate Runners 是首要任務(wù)，用于為后續(xù)工作分配 Runners 并創(chuàng)建全局版本標(biāo)簽。例如，使用 EC2 時，Allocate Runners 將通過 EC2 API（由 ec2-github-runner Action 實現(xiàn)）分配相應(yīng)平臺的 EC2 實例。未來計劃引入更精確的選擇算法以優(yōu)化 Runner 分配成本。
- 實現(xiàn)全球統(tǒng)一流程：避免創(chuàng)建功能相似的 GitHub Actions 分支，以減少維護(hù)負(fù)擔(dān)。為促進(jìn)透明的開源開發(fā)，所有內(nèi)部使用的構(gòu)建流程已合并至主要的 GreptimeDB 存儲庫。代碼若為開源，則軟件產(chǎn)品和構(gòu)建過程也應(yīng)同樣開放。
- 在 GitHub 存儲庫中合理使用變量和秘密：不應(yīng)把大部分外部參數(shù)當(dāng)作機密處理。一些非機密的外部參數(shù)應(yīng)配置為 GitHub 變量，以便未來可以方便修改。應(yīng)避免在 YAML 中硬編碼將需要頻繁修改的變量。
展望
GreptimeDB 對發(fā)布流水線的重構(gòu)只是其走向成熟旅程中的一個環(huán)節(jié)。我們正朝著構(gòu)建更高質(zhì)量、更強大的 CI 努力發(fā)展：
- 拓展平臺生態(tài)系統(tǒng)： 我們 Windows 系統(tǒng)軟件產(chǎn)品即將發(fā)布，屆時歡迎來測試和體驗。
- 增加自動化測試種類：在未來的計劃中，我們將在 CI 流程中融合各類測試方式，例如混沌測試和性能測試，以持續(xù)提高軟件的質(zhì)量。
- 優(yōu)化 CI 使用成本：通過精確分配各類 Runners，滿足不同用例的需求，我們計劃使整個 CI 運行更為經(jīng)濟(jì)和高效。
- 提升構(gòu)建效能：雖然重構(gòu)發(fā)布流水線在一定程度上對構(gòu)建性能造成影響（＃2113），但我們計劃通過采用更智能的構(gòu)建緩存技術(shù)，進(jìn)一步加速構(gòu)建過程。
- 強化軟件供應(yīng)鏈的安全性：在現(xiàn)代軟件制品管理中，軟件供應(yīng)鏈安全日漸重要。作為一個開源項目，我們將確保軟件產(chǎn)品的安全性、可信性和透明度。我們計劃在發(fā)布流程中加入基本安全措施，如 SBOM 管理、軟件簽名和驗證等。
雖然充分利用 GitHub Actions 存在挑戰(zhàn)，我們?nèi)詫猿植恍傅馗倪M(jìn)。如你對此感興趣并想要深入了解，歡迎加入我們在 Slack 上的社區(qū)進(jìn)行討論！你的建議對我們下一階段的改進(jìn)很可能會起到關(guān)鍵作用。
譯者介紹
劉汪洋，51CTO社區(qū)編輯，昵稱：明明如月，一個擁有 5 年開發(fā)經(jīng)驗的某大廠高級 Java 工程師，擁有多個主流技術(shù)博客平臺博客專家稱號。
標(biāo)題：Practical Tips for Refactoring Release CI using GitHub Actions，作者：Greptime
