注意：GitHub Enterprise Server 目前不支持 GitHub 托管的运行器。 可以在 GitHub public roadmap 上查看有关未来支持计划的更多信息。
关于持续部署
持续部署 (CD) 是使用自动化发布和部署软件更新的做法。 作为典型 CD 过程的一部分，代码在部署之前会自动构建并测试。
持续部署通常与持续集成相结合。 有关持续集成的详细信息，请参阅“关于持续集成”。
关于使用 GitHub Actions 的持续部署
您可以设置 GitHub Actions 工作流程来部署软件产品。 要验证产品是否按预期工作，您的工作流程可以在存储库中构建代码，并在部署之前运行测试。
您可以配置 CD 工作流程在发生 GitHub Enterprise Server 事件（例如，将新代码推送到存储库的默认分支）时运行、按设定的时间表运行、手动运行或者在使用存储库分发 web 挂钩的外部事件发生时运行。 有关工作流何时可以运行的详细信息，请参阅“触发工作流的事件”。
GitHub Actions 提供的功能使您可以更好地控制部署。 例如，您可以使用环境来要求批准才能继续作业，限制哪些分支可以触发工作流程，或限制对机密的访问。 你可以使用并发性将 CD 管道限制为最多一个正在进行的部署和一个挂起的部署。 若需详细了解这些功能，请参阅“使用 GitHub Actions 进行部署”和“使用环境进行部署”。
使用 OpenID Connect 访问云资源
如果 GitHub Actions 工作流需要访问支持 OpenID Connect (OIDC) 的云提供商提供的资源，则可以将工作流配置为直接向云提供商进行身份验证。 这样就可以停止将这些凭据存储为长期存在的机密，并提供其他安全优势。 有关详细信息，请参阅“关于使用 OpenID Connect 进行安全强化”。
初学者工作流程和第三方操作
GitHub Enterprise Server 为 Azure Web 应用等多种流行服务提供部署入门工作流。 若要了解如何开始使用入门工作流，请参阅“使用入门工作流程”或浏览部署入门工作流的完整列表。 还可以查看有关特定部署工作流的详细指南，例如“将 Node.js 部署到 Azure App Service”。
许多服务提供商还提供针对 GitHub Marketplace 的操作，用于部署到他们的服务。 有关完整列表，请参阅 GitHub Marketplace。