关于持续部署
持续部署 (CD) 是一种利用自动化发布和部署软件更新的实践。作为典型 CD 流程的一部分，代码会在部署前自动构建和测试。
持续部署通常与持续集成相结合。有关持续集成的更多信息，请参阅“关于使用 GitHub Actions 进行持续集成”。
关于使用 GitHub Actions 进行持续部署
您可以设置一个 GitHub Actions 工作流来部署您的软件产品。为了验证您的产品按预期工作，您的工作流可以在部署前构建存储库中的代码并运行您的测试。
您可以配置您的 CD 工作流，使其在发生 GitHub 事件时运行（例如，当新代码推送到存储库的默认分支时）、按设定的时间表运行、手动运行或当使用存储库调度 Webhook 发生外部事件时运行。有关工作流何时可以运行的更多信息，请参阅“触发工作流的事件”。
GitHub Actions 提供了一些功能，让您可以更好地控制部署。例如，您可以使用环境来要求在作业继续执行之前获得批准，限制哪些分支可以触发工作流，或限制对密钥的访问。您可以使用并发性将您的持续交付管道限制为最多一个正在进行的部署和一个挂起的部署。有关这些功能的更多信息，请参阅“使用 GitHub Actions 部署”和“管理部署环境”。
使用 OpenID Connect 访问云资源
如果您的 GitHub Actions 工作流需要访问支持 OpenID Connect (OIDC) 的云提供商的资源，您可以配置您的工作流以直接向云提供商进行身份验证。这将使您能够停止将这些凭据存储为长期密钥，并提供其他安全优势。有关更多信息，请参阅“关于使用 OpenID Connect 加强安全性”
工作流模板和第三方操作
GitHub 为多种流行服务（例如 Azure Web App）提供了部署工作流模板。要了解如何开始使用工作流模板，请参阅“使用工作流模板”或浏览完整的部署工作流模板列表。您还可以查看我们针对特定部署工作流的更详细指南，例如“将 Node.js 部署到 Azure 应用服务”。
许多服务提供商还在 GitHub Marketplace 上提供用于部署到其服务的 action。有关完整列表，请参阅GitHub Marketplace。