在雲端持續整合（CI）服務主導的開發環境中，一個名為 gh-signoff 的新 GitHub CLI 擴展出現了，它挑戰了關於測試自動化的傳統觀念。這個由 Basecamp 開發的工具允許開發者在本地執行測試並手動確認他們的工作，無需使用遠端 CI 執行器即可建立透過的狀態檢查。
關於 gh-signoff 的要點
- 目的：允許開發者在本地執行測試並手動確認他們的工作
- 工作原理：透過命令
gh signoff建立一個透過的 GitHub 狀態檢查 - 執行的檢查：僅驗證沒有未提交的 Git 更改
- 不會：自動執行測試或釋出測試結果
- 安裝方法：
gh extension install basecamp/gh-signoff - 許可證：MIT
本地 CI 與雲端 CI：社群意見分歧
gh-signoff 的推出在開發者社群中引發了激烈的討論。支持者認為，現代開發者的計算機已經足夠強大，可以處理以前需要雲基礎設施才能完成的測試工作負載。正如該擴充套件的描述所述，現在的開發筆記型電腦非常快。它們長期被低效利用。而且你已經擁有它們。雲 CI 服務通常速度慢、成本高，且需要租用。
然而，許多開發者對這種方法表示嚴重擔憂。主要批評集中在可重現性和可靠性上。一位評論者指出，該工具本質上是建立一個透過狀態，而沒有任何驗證測試是否真的運行了：
「這只是在倉庫中建立一個透過狀態，以便 PR 可以被合併。開發者並沒有義務真正在本地執行測試，所以你可以直接透過停用狀態檢查來節省時間。」
這突顯了軟體開發過程中信任與驗證之間的基本張力。
開發團隊中的信任因素
gh-signoff 方法建立在開發團隊內部信任的基礎上。該工具的捍衛者指出，即使有傳統的 CI，決心繞過檢查的開發者也可以透過修改測試程式碼來實現。他們認為，使籤核過程明確化可以創造責任感。
批評者則反駁說，問題不在於信任，而在於人為錯誤。正如一位擁有25年以上編碼經驗的開發者解釋的那樣，即使是最謹慎的開發者也會犯錯誤——忘記刪除除錯輸出、更新異常處理或確保跨平臺相容性。在獨立機器上執行構建有助於捕獲這些錯誤，無論開發者的意圖或注意力如何。
隔離和環境一致性問題
許多評論者強調，CI 的價值在於提供一致的、隔離的環境。當測試在開發者機器上執行時，它們可能會因為特定於該環境的依賴項或配置而透過——導致經典的在我的機器上可以執行問題。一些開發者建議，如果希望本地執行，使用容器化或虛擬機器將是確保環境一致性的必要手段。
對於需要在多個作業系統或硬體配置上進行測試的複雜系統的組織來說，本地 CI 變得越來越不切實際。正如一位 PyTorch 開發者指出的那樣，雲 CI 提供了必要的並行化和環境多樣性，這在本地是不可能複製的。
成本與控制的權衡
CI 的財務方面不容忽視。隨著組織的成長，雲 CI 成本可能變得相當可觀。一位評論者觀察到，一旦你的工程組織達到一定規模，你可能會在 CI 計算上花費令人瞠目的金額。gh-signoff 方法透過利用現有的開發者硬體，有可能提供顯著的成本節約。
然而，這帶來了可審計性和合規性方面的權衡。幾位評論者指出，集中式 CI 系統提供了測試過程的文件證據——這對於受審計或監管要求約束的組織尤為重要。
gh-signoff 工具代表了重新思考開發工作流的一個有趣實驗，但社群共識表明，它可能最適合具有高度信任、簡單應用和最低合規要求的小型團隊。對於大多陣列織，特別是那些規模較大的組織，傳統 CI 系統繼續提供的好處超過了它們的成本。
參考：gh-signoff