使用 GitHub Actions 部署

简介

GitHub Actions 提供了可用于控制部署的功能。您可以

• 使用各种事件触发工作流。
• 配置环境以在作业继续之前设置规则，并限制对密钥的访问。
• 使用并发性控制同时运行的部署数量。

有关持续部署的更多信息，请参阅“关于 GitHub Actions 的持续部署”。

先决条件

您应该熟悉 GitHub Actions 的语法。有关更多信息，请参阅“编写工作流”。

触发您的部署

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

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

• 向 `main` 分支推送代码。
• 打开、同步或重新打开目标为 `main` 分支的拉取请求。
• 有人手动触发它。

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

有关更多信息，请参阅“触发工作流的事件”。

使用环境

环境用于描述一般的部署目标，例如production、staging或development。当 GitHub Actions 工作流部署到某个环境时，该环境将显示在仓库的主页上。您可以使用环境来要求批准作业才能继续进行，限制哪些分支可以触发工作流，使用自定义部署保护规则来控制部署，或限制对密钥的访问。有关创建环境的更多信息，请参阅“管理部署环境”。

使用并发

并发确保一次只有一个使用相同并发组的作业或工作流运行。您可以使用并发来确保环境一次最多只有一个部署正在进行，并且只有一个部署处于挂起状态。有关并发的更多信息，请参阅“控制工作流和作业的并发性”。

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

name: Deployment

concurrency: production

on:
  push:
    branches:
      - main

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

您也可以在作业级别指定并发。即使并发作业处于pending状态，这也允许工作流中的其他作业继续进行。

name: Deployment

on:
  push:
    branches:
      - main

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

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

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 工作流部署到某个环境时，该环境将显示在仓库的主页上。有关查看对环境的部署的更多信息，请参阅“查看部署历史记录”。

监控工作流运行

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

您还可以查看每次工作流运行的日志和工作流运行的历史记录。有关更多信息，请参阅“查看工作流运行历史记录”。

通过应用跟踪部署

如果您的 GitHub 个人帐户或组织已与 Microsoft Teams 或 Slack 集成，则您可以通过 Microsoft Teams 或 Slack 跟踪使用环境的部署。例如，当部署正在等待批准、部署已获批准或部署状态发生更改时，您可以通过应用接收通知。有关集成 Microsoft Teams 或 Slack 的更多信息，请参阅“精选的 GitHub 集成”。

您还可以构建一个使用部署和部署状态 Webhook 来跟踪部署的应用。当引用环境的工作流作业运行时，它会创建一个具有设置为环境名称的environment属性的部署对象。随着工作流的进行，它还会创建具有设置为环境名称的environment属性、设置为环境 URL（如果在工作流中指定）的environment_url属性和设置为作业状态的state属性的部署状态对象。有关更多信息，请参阅“GitHub 应用文档”和“Webhook 事件和有效负载”。

选择运行器

您可以在 GitHub 托管的运行器或自托管的运行器上运行您的部署工作流。来自 GitHub 托管运行器的流量可能来自各种网络地址。如果您正在部署到内部环境，并且您的公司限制了对私有网络的外部流量，则在 GitHub 托管的运行器上运行的 GitHub Actions 工作流可能无法与您的内部服务或资源通信。为了克服这个问题，您可以托管您自己的运行器。有关更多信息，请参阅“关于自托管运行器”和“使用 GitHub 托管的运行器”。

显示状态徽章

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

有关更多信息，请参阅“添加工作流状态徽章”。

查找部署示例

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

GitHub 为多种流行服务（例如 Azure Web App）提供部署工作流模板。要了解如何开始使用工作流模板，请参阅“使用工作流模板”或浏览完整的部署工作流模板列表。您还可以查看我们针对特定部署工作流的更详细的指南，例如“将 Node.js 部署到 Azure App Service”。

许多服务提供商还在 GitHub Marketplace 上提供用于部署到其服务的 Actions。有关完整列表，请参阅GitHub Marketplace。