GHES 上的开发人员体验

  • 5 分钟

从用户界面的角度来看，GHES 看起来很熟悉。 但是，开发人员体验在有意义的方面有所不同，尤其是在自动化、集成和工具方面。

在本单元中，你将学习

  • GitHub Actions 在 GHES 上的工作原理

  • 开发人员必须自行管理哪些工具

  • 哪些云原生功能不可用

  • 如何使工作流适应受约束的环境

GHES 上的 GitHub Actions

  • 支持 GitHub Actions，但工作流必须使用自托管运行器。

  • 你的组织负责预配、缩放、修补和维护这些运行器。

  • 如果运行器处于离线或过时状态，工作流将失败，不会自动回退。

  • 网络限制很常见;外部访问可能需要代理或镜像。

  • GHES 主要依赖于自托管运行器。 GitHub Enterprise Cloud 中提供的 GitHub 托管运行程序通常不可用，尽管某些混合方案可能通过 GitHub Connect 支持，具体取决于企业配置。

软件包、安全性和自动化

  • GitHub 包（npm、Docker 等）在 GHES 内部可用并托管。

  • 高级安全功能（例如代码扫描、机密扫描）受适当的许可支持。

  • 这些功能通常需要手动设置，例如安装扫描引擎或从开发人员的角度来看启用机密检测，启用过程与 GitHub Enterprise Cloud （GHEC）上没有什么不同。

  • 默认情况下会禁用许多功能，具体取决于与 DevOps 或平台团队的协调。

不支持或受限的功能

  • 自 GHES 3.19 起，不支持 GitHub Codespaces。

  • GHES 不支持 GitHub Copilot。 Copilot 可用作受支持 IDE 中的独立功能，但 GHES Web 界面上不提供 Copilot 功能，并且功能在 Internet 访问受限的环境中可能会进一步受到限制。

  • 直接从 GitHub.com 访问公共 GitHub Actions 库需要 GitHub Connect。 如果没有该功能，则必须将操作手动同步到本地实例。

  • 虽然 Webhook 和 SaaS 工具不使用 GitHub Connect，但它们需要出站网络路由（代理/防火墙）才能访问外部终结点。

  • 功能可用性各不相同，开发人员应在依赖云工作流之前确认已启用的内容。

开发人员应在依赖于云优先工作流之前验证可用性。

关键要点：GHES 开发人员的体验受到自主管理的基础设施自动化、集成和可用功能的影响，而这些功能具体依赖于您环境中部署、授权和启用的内容。

现在，你已经了解了 GHES 在日常开发工作流中的差别，接下来即可完成下一步。

下一单元介绍 GitHub Connect 和混合方案，这些方案使用所选 GitHub.com 功能扩展 GHES。