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