使用 GitHub Actions 进行部署

先决条件

您应该熟悉 GitHub Actions 的语法。 有关详细信息，请参阅“AUTOTITLE”。

触发部署

您可以使用各种事件来触发您的部署工作流程。 一些最常见的事件包括：、 和 。

例如，具有以下触发器的工作流在以下情况下会运行：

• 存在针对 分支的推送。
• 以 分支为目标的拉取请求已打开、已同步或重新打开。
• 有人手动触发它。

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  workflow_dispatch:

有关详细信息，请参阅“AUTOTITLE”。

使用环境

环境用于描述常规部署目标，例如 production、staging 或 development。 当 GitHub Actions 工作流部署到某个环境时，该环境将显示在存储库的主页上。 可以使用环境来要求审批作业以继续，限制可以触发工作流的分支，使用自定义部署保护规则控制部署，或限制对机密的访问权限。 有关创建环境的详细信息，请参阅“管理部署环境”。

您可以使用保护规则和机密配置环境。 当工作流程引用环境时，作业在环境的所有保护规则通过之前不会开始。 在所有部署保护规则通过之前，作业也不能访问在环境中定义的机密。 若要了解详细信息，请参阅本文中的使用自定义部署保护规则。

使用并发处理

并发确保只有使用相同并发组的单一作业或工作流程才会同时运行。 您可以使用并发机制，以确保环境中同时最多只有一个正在进行的部署和一个待处理的部署。 有关并发的更多信息，请参阅 AUTOTITLE。

例如，当以下工作流运行时，如果使用 并发组的任何作业或工作流正在进行中，则它将暂停并且状态为 。 它还将取消使用 并发组且状态为 的任何作业或工作流。 这意味着，在使用并发组时，最多会有一个正在运行的作业和一个待处理的作业或工作流。

name: Deployment

concurrency: production

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        # ...deployment-specific steps

您也可以在作业级别指定并发性。 这将允许工作流中的其他作业继续，即使并发作业的状态为 。

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    concurrency: production
    steps:
      - name: deploy
        # ...deployment-specific steps

还可以使用 取消同一并发组中任何当前正在运行的作业或工作流。

name: Deployment

concurrency:
  group: production
  cancel-in-progress: true

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        # ...deployment-specific steps

有关如何编写特定于部署的步骤的指导，请参阅“查找部署示例”。

查看部署历史记录

当 GitHub Actions 工作流部署到某个环境时，该环境将显示在存储库的主页上。 有关如何查看环境部署的详细信息，请参阅“AUTOTITLE”。

监控工作流程运行

每个工作流程运行都会生成一个实时图表，说明运行进度。 您可以使用此图表来监控和调试部署。 有关详细信息，请参阅“AUTOTITLE”。

您还可以查看每个工作流程运行的日志和工作流程运行的历史记录。 有关详细信息，请参阅“AUTOTITLE”。

在工作流中使用必要的审核

引用配置了所需审查者的环境的作业将等待审批后再开始。 当作业正在等待批准时，其状态为“等待”。 如果作业在 30 天内未获得批准，它将自动失败。

有关环境和所需的审批的详细信息，请参阅“AUTOTITLE”。 有关如何使用 REST API 查看部署的信息，请参阅“AUTOTITLE”。

使用自定义部署保护规则

可以启用自己的自定义保护规则来限制第三方服务的部署。 例如，可以使用 Datadog、Honeycomb 和 ServiceNow 等服务为部署到 GitHub 提供自动审批。

自定义部署保护规则由 GitHub Apps 提供支持，并基于 Webhooks 和回调函数运行。 工作流作业的批准或拒绝基于 Webhook 的使用情况。 有关详细信息，请参阅 AUTOTITLE 和“批准或拒绝部署”。

创建自定义部署保护规则并将其安装在存储库中后，自定义部署保护规则将自动用于存储库中的所有环境。

可以基于任何外部服务中定义的条件（例如 IT 服务管理 (ITSM) 系统中的已批准票证、依赖项上易受攻击的扫描结果或云资源的稳定运行状况指标）批准或拒绝环境部署。 批准或拒绝部署的决定由集成的第三方应用程序以及在其中定义的限制条件决定。 下面是几个可以为其创建部署保护规则的用例。

• ITSM 与安全运营：可以通过验证用于验证部署就绪情况的质量、安全性和合规性过程来检查服务就绪情况。
• 可观测性系统：可以咨询监视或可观测性系统（资产性能管理系统和日志记录聚合器、云资源健康验证系统等），以验证安全性和部署就绪情况。
• 代码质量和测试工具：可以检查需要部署到环境的 CI 生成的自动测试。

或者，可以为上述任一用例编写自己的保护规则，也可以定义任何自定义逻辑，以安全地批准或拒绝从预生产环境到生产环境的部署。

通过应用跟踪部署

你还可以构建一个应用，该应用使用部署和部署状态 web 挂钩来跟踪部署。 当引用环境的工作流作业运行时，它将创建一个部署对象并将 environment 属性设置为环境名称。 随着工作流的进行，它还将创建部署状态对象，并将 environment 属性设置为环境名称，将 environment_url 属性设置为环境的 URL（如果在工作流中指定），以及将 state 属性设置为作业的状态。 有关详细信息，请参阅“AUTOTITLE”和“AUTOTITLE”。

选择运行器

您可以在 GitHub 托管的运行器或自托管运行器上运行部署工作流程。 来自 GitHub 托管的运行器的流量可能来自各种网络地址。 如果要部署到内部环境，并且公司将外部流量限制到专用网络，则在 GitHub 托管的运行器上运行的 GitHub Actions 工作流可能无法与内部服务或资源通信。 为了克服这一点，您可以托管自己的运行器。 有关详细信息，请参阅 AUTOTITLE 和 AUTOTITLE。

显示状态徽章

您可以使用状态徽章来显示您的部署工作流程状态。 状态徽章显示工作流程目前失败还是通过。 添加状态徽章的常见位置是存储库的 README.md 文件，但也可将其添加到你喜欢的任何网页。 默认情况下，徽章显示默认分支的状态。 如果默认分支上没有工作流运行，它将显示所有分支中最近运行的状态。 也可以在 URL 中使用 branch 和 event 查询参数显示特定分支或事件的工作流运行的状态。

有关详细信息，请参阅“AUTOTITLE”。

查找部署示例

本文演示了可添加到部署工作流程的 GitHub Actions 的功能。

GitHub 为 Azure Web 应用等多种流行服务提供部署工作流模板。 若要了解如何开始使用工作流模板，请参阅 使用工作流模板 或浏览部署工作流模板的完整列表。 还可以查看有关特定部署工作流的详细指南，例如 将 Node.js 部署到Azure App Service。

许多服务提供商还提供针对 GitHub Marketplace 的操作，用于部署到他们的服务。 有关完整列表，请参阅 GitHub Marketplace。