简介
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 工作流部署到某个环境时,该环境将显示在存储库的主页上。 可以使用环境来要求批准作业才能继续,限制哪些分支可以触发工作流 ,使用自定义部署保护规则 控制部署,或限制对机密的访问。 有关创建环境的详细信息,请参阅“管理部署环境”。
使用并发
并发确保只有使用相同并发组的单一作业或工作流程才会同时运行。 您可以使用并发,以便环境中每次最多有一个正在进行的部署和一个待处理的部署。 有关并发的详细信息,请参阅“控制工作流和作业的并发性”。
Note
concurrency
和 environment
未连接。 并发值可以是任何字符串;它无需是环境名称。 此外,如果另一个工作流程使用相同的环境,但未指定并发性,则该工作流程将不受任何并发规则的约束。
例如,当以下工作流运行时,如果使用 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 集成”。
你还可以构建一个应用,该应用使用部署和部署状态 web 挂钩来跟踪部署。 当引用环境的工作流作业运行时,它将创建一个部署对象并将 environment
属性设置为环境名称。 随着工作流的进行,它还将创建部署状态对象,并将 environment
属性设置为环境名称,将 environment_url
属性设置为环境的 URL(如果在工作流中指定),以及将 state
属性设置为作业的状态。 有关详细信息,请参阅“GitHub 应用文档”和“Webhook 事件和有效负载”。
选择运行器
您可以在 GitHub 托管的运行器或自托管运行器上运行部署工作流程。 来自 GitHub 托管的运行器的流量可能来自各种网络地址。 如果要部署到内部环境,并且公司将外部流量限制到专用网络,则在 GitHub 托管的运行器上运行的 GitHub Actions 工作流可能无法与内部服务或资源通信。 为了克服这一点,您可以托管自己的运行器。 有关详细信息,请参阅 关于自托管运行程序 和 使用 GitHub 托管的运行器。
显示状态徽章
您可以使用状态徽章来显示您的部署工作流程状态。 状态徽章显示工作流程目前失败还是通过。 添加状态徽章的常见位置是存储库的 README.md
文件,但也可将其添加到你喜欢的任何网页。 默认情况下,徽章显示默认分支的状态。 如果默认分支上没有工作流运行,它将显示所有分支中最近运行的状态。 也可以在 URL 中使用 branch
和 event
查询参数显示特定分支或事件的工作流运行的状态。
有关详细信息,请参阅“添加工作流状态徽章”。
查找部署示例
本文演示了可添加到部署工作流程的 GitHub Actions 的功能。
GitHub 为 Azure Web 应用等多种流行服务提供部署工作流模板。 若要了解如何开始使用工作流模板,请参阅“使用工作流模板”或浏览部署工作流模板的完整列表。 还可以查看有关特定部署工作流的详细指南,例如“将 Node.js 部署到 Azure App Service”。
许多服务提供商还提供针对 GitHub Marketplace 的操作,用于部署到他们的服务。 有关完整列表,请参阅 GitHub Marketplace。