開發者在 GHES 上的經驗分享

  • 5 分鐘

從使用者介面的角度來看，GHES 看起來很熟悉。 然而，開發者的體驗在自動化、整合與工具方面有顯著差異。

在這個單元裡，你會學到東西

  • GitHub Actions 在 GHES 上的運作方式

  • 開發人員必須自行管理的工具

  • 哪些雲端原生功能無法使用？

  • 如何調整工作流程以適應受限環境

GitHub 在 GHES 上的操作

  • GitHub Actions 受支援，但工作流程必須使用自我裝載執行器。

  • 你的組織負責配置、擴展、修補及維護這些執行器。

  • 如果執行器離線或版本過舊，工作流程會失敗 - 不會自動回復。

  • 網路限制很常見;外部存取可能需要代理或鏡像。

  • GHES 主要依賴自我裝載執行器。 GitHub Enterprise Cloud 中可用的 GitHub 裝載執行器通常無法使用，但根據企業組態，部分混合情境可能透過 GitHub Connect 受支援。

套件、安全性與自動化

  • GitHub 套件（npm、Docker 等）在 GHES 內部可取得並託管。

  • 進階安全功能（例如程式碼掃描、秘密掃描）在適當授權下皆有支援。

  • 這些功能通常需要手動設定，例如安裝掃描引擎或啟用秘密偵測功能，但從開發者的角度來看，啟用過程與 GitHub Enterprise Cloud（GHEC）並無不同。

  • 許多功能預設是被關閉的，且依賴與 DevOps 或平台團隊的協調。

不支援或功能有限

  • GitHub Codespaces 從 GHES 3.19 起不再支援。

  • GitHub Copilot 在 GHES 上不被支援。 Copilot 可在支援的 IDE 中作為獨立功能使用，但 GHES 網頁介面無法提供 Copilot 功能，且在網路存取受限的環境中功能可能進一步受限。

  • 直接從 GitHub.com 存取公開的 GitHub Actions 函式庫需要 GitHub Connect。 沒有它，動作必須手動同步到你的本地實例。

  • 雖然 webhook 和 SaaS 工具不使用 GitHub Connect，但它們需要外部網路路由（代理/防火牆）才能到達外部端點。

  • 功能可用性因人而異——開發者應該先確認啟用了哪些功能，再決定是否依賴雲端工作流程。

開發者應先確認可用性，再依賴雲端優先工作流程。

重點摘要：GHES 開發者的體驗是由自我管理的基礎設施所塑造——自動化、整合，甚至「可用功能」都可能取決於你環境中部署、授權和啟用的內容。

既然你已經看到 GHES 在日常開發工作流程中的不同，你已經準備好邁向下一步。

下一單元介紹 GitHub Connect 及混合情境，擴充 GHES 的部分 GitHub.com 功能。