您可以使用 GitHub 操作直接在 GitHub 存储库中创建自定义持续部署 (CD) 工作流。
About continuous deployment
持续部署 (CD) 是使用自动化来发布和部署软件更新的做法。作为典型 CD 流程的一部分，代码会在部署前自动构建和测试。
持续部署通常与持续集成相结合。有关持续集成的更多信息，请参阅“关于持续集成”。
About continuous deployment using GitHub Actions
您可以设置 GitHub 操作工作流来部署您的软件产品。为了验证您的产品是否按预期工作，您的工作流程可以在您的存储库中构建代码并在部署之前运行您的测试。
您可以将 CD 工作流配置为在 GitHub 事件发生时（例如，将新代码推送到存储库的默认分支时）、按设定的计划、手动或在使用存储库调度 Webhook 发生外部事件时运行。有关何时可以运行工作流的更多信息，请参阅“触发工作流的事件”。
GitHub Actions 提供的功能可让您更好地控制部署。例如，您可以使用 environments 要求批准作业才能继续、限制哪些分支可以触发工作流或限制对机密的访问。您可以使用并发将 CD 管道限制为最多一个正在进行的部署和一个待处理的部署。有关这些功能的更多信息，请参阅“使用 GitHub 操作进行部署”和“使用环境进行部署”。
Using environments for deployment
您可以使用 protection rules 和 secrets 配置环境。 在运行或访问环境的 secrets 之前，引用环境的工作流作业必须遵循环境的任何保护规则。
什么是 environments
环境用于描述一般部署目标，如生产、暂存或开发。 当 GitHub Actions 工作流部署到环境时，环境会显示在存储库的主页上。有关查看环境部署的更多信息，请参阅“查看部署历史记录”。
您可以使用保护规则和 secrets 配置环境。 当工作流作业引用环境时，在所有环境保护规则都通过之前，作业不会启动。在所有环境保护规则都通过之前，作业也无法访问环境中定义的机密。
Environment protection rules
环境保护规则要求通过特定条件才能继续进行引用环境的作业。您可以使用环保规则来要求手动审批、延迟作业或将环境限制为某些分支机构。
Required reviewers
使用必需的审阅者来要求特定人员或团队批准引用环境的工作流作业。您最多可以列出六个用户或团队作为审阅者。审阅者必须至少具有对存储库的读取权限。 只有一名所需的审阅者需要批准作业才能继续进行。
Environment secrets
存储在环境中的机密仅可用于引用该环境的工作流作业。 如果环境需要批准，则在所需的审阅者之一批准之前，作业无法访问环境机密。
Using an environment
工作流中的每个作业都可以引用一个环境。在将引用环境的作业发送到运行程序之前，必须通过为环境配置的任何保护规则。 只有在将作业发送给运行程序后，作业才能访问环境的机密。
当工作流引用环境时，环境将出现在存储库的部署中。 有关查看当前和以前部署的详细信息，请参阅“查看部署历史记录”。
您可以为工作流程中的每个作业指定一个环境。 为此，添加一个 jobs. .environment 键，后跟环境名称。
例如，此工作流将使用称为 production 的环境。
当上述工作流运行时，部署作业将遵循为生产环境配置的任何规则。 例如，如果环境需要审阅者，则作业将暂停，直到其中一位审阅者批准该作业。
您还可以为环境指定 URL。 指定的 URL 将显示在存储库的部署页面（通过单击存储库主页上的环境访问）和工作流运行的可视化图中。 如果拉取请求触发了工作流，则 URL 还会在拉取请求时间线中显示为“查看部署”按钮。
How environments relate to deployments
当引用环境的工作流作业运行时，它会创建一个部署对象，并将环境属性设置为您的环境名称。 随着工作流的进行，它还会创建部署状态对象，其中 environment 属性设置为您的环境名称，environment_url 属性设置为 environment 的 URL（如果在工作流中指定），以及 state 属性设置为工作。
您可以通过 REST API 或 GraphQL API 访问这些对象。 您还可以订阅这些 webhook 事件。
