Deploying with GitHub Actions

Learn how to control deployments with features like environments and concurrency.

注意: GitHub Actions 目前正在测试用于 GitHub AE 。

简介

GitHub Actions offers features that let you control deployments. 您可以:

  • Trigger workflows with a variety of events.
  • Configure environments to set rules before a job can proceed and to limit access to secrets.
  • Use concurrency to control the number of deployments running at a time.

For more information about continuous deployment, see "About continuous deployment."

基本要求

You should be familiar with the syntax for GitHub Actions. 更多信息请参阅“Learn GitHub Actions”。

Triggering your deployment

You can use a variety of events to trigger your deployment workflow. Some of the most common are: pull_request, push, and workflow_dispatch.

For example, a workflow with the following triggers runs whenever:

  • There is a push to the main branch.
  • A pull request targeting the main branch is opened, synchronized, or reopened.
  • Someone manually triggers it.
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  workflow_dispatch:

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

使用环境

Environments are used to describe a general deployment target like production, staging, or development. When a GitHub Actions workflow deploys to an environment, the environment is displayed on the main page of the repository. You can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, or limit access to secrets. For more information about creating environments, see "Using environments for deployment."

Using concurrency

Concurrency 确保只有使用相同并发组的单一作业或工作流程才会同时运行。 您可以使用并发,以便环境中每次最多有一个正在进行的部署和一个待处理的部署。

Note: concurrency and environment are not connected. The concurrency value can be any string; it does not need to be an environment name. Additionally, if another workflow uses the same environment but does not specify concurrency, that workflow will not be subject to any concurrency rules.

For example, when the following workflow runs, it will be paused with the status pending if any job or workflow that uses the production concurrency group is in progress. It will also cancel any job or workflow that uses the production concurrency group and has the status pending. This means that there will be a maximum of one running and one pending job or workflow in that uses the production concurrency group.

name: Deployment

concurrency: production

on:
  push:
    branches:
      - main

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

You can also specify concurrency at the job level. This will allow other jobs in the workflow to proceed even if the concurrent job is pending.

name: Deployment

on:
  push:
    branches:
      - main

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

You can also use cancel-in-progress to cancel any currently running job or workflow in the same concurrency group.

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

查看部署历史记录

When a GitHub Actions workflow deploys to an environment, the environment is displayed on the main page of the repository. For more information about viewing deployments to environments, see "Viewing deployment history."

Monitoring workflow runs

每个工作流程运行都会生成一个实时图表,说明运行进度。 You can use this graph to monitor and debug deployments. For more information see, "Using the visualization graph."

You can also view the logs of each workflow run and the history of workflow runs. 更多信息请参阅“查看工作流程运行历史记录”。

Tracking deployments through apps

You can also build an app that uses deployment and deployment status webhooks to track deployments. When a workflow job that references an environment runs, it creates a deployment object with the environment property set to the name of your environment. As the workflow progresses, it also creates deployment status objects with the environment property set to the name of your environment, the environment_url property set to the URL for environment (if specified in the workflow), and the state property set to the status of the job. For more information, see "Apps" and "Webhook events and payloads."

Displaying a status badge

You can use a status badge to display the status of your deployment workflow. 状态徽章显示工作流程目前失败还是通过。 添加状态徽章的常见位置是仓库的 README.md 文件,但也可将其添加到您喜欢的任何网页。 默认情况下,徽章显示默认分支的状态。 您也可以在 URL 中使用 branchevent 查询参数显示特定分支或事件运行的工作流程状态。

示例状态徽章

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

后续步骤

This article demonstrated features of GitHub Actions that you can add to your deployment workflows.

GitHub AE offers CD workflow templates for several popular services, such as Azure Web App. To learn how to get started using a workflow template, see "Using workflow templates" or browse the full list of deployment workflow templates. You can also check out our more detailed guides for specific deployment workflows, such as "Deploying to Azure App Service."

Many service providers also offer actions on GitHub Marketplace for deploying to their service. For the full list, see GitHub Marketplace.

此文档对您有帮助吗?

隐私政策

帮助我们创建出色的文档!

所有 GitHub 文档都是开源的。看到错误或不清楚的内容了吗?提交拉取请求。

做出贡献

或者, 了解如何参与。