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