Deploying with GitHub Actions

Introduction

GitHub Actions offers features that let you control deployments. You can:

• 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 with GitHub Actions.

Prerequisites

You should be familiar with the syntax for GitHub Actions. For more information, see Написание рабочих процессов.

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:

For more information, see События, инициирующие рабочие процессы.

Using environments

Среды используются для описания общего целевого объекта развертывания, такого как production, staging или development. Когда рабочий процесс GitHub Actions выполняет развертывание в среде, эта среда отображается на главной странице репозитория. Вы можете использовать среды, чтобы требовать утверждения для продолжения задания, ограничить, какие ветви могут активировать рабочий процесс, воротные развертывания с помощью настраиваемых правил защиты развертывания или ограничить доступ к секретам. Дополнительные сведения о создании сред см. в разделе Управление средами для развертывания.

Using concurrency

Concurrency ensures that only a single job or workflow using the same concurrency group will run at a time. You can use concurrency so that an environment has a maximum of one deployment in progress and one deployment pending at a time. For more information about concurrency, see Управление параллелизмом рабочих процессов и заданий.

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

For guidance on writing deployment-specific steps, see Finding deployment examples.

Viewing deployment history

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 Просмотр журнала развертывания.

Monitoring workflow runs

Every workflow run generates a real-time graph that illustrates the run progress. You can use this graph to monitor and debug deployments. For more information see, Использование графа визуализации.

You can also view the logs of each workflow run and the history of workflow runs. For more information, see Просмотр журнала выполнения рабочего процесса.

Tracking deployments through apps

If your personal account or organization on GitHub is integrated with Microsoft Teams or Slack, you can track deployments that use environments through Microsoft Teams or Slack. For example, you can receive notifications through the app when a deployment is pending approval, when a deployment is approved, or when the deployment status changes. For more information about integrating Microsoft Teams or Slack, see Рекомендуемые интеграции GitHub.

You can also build an app that uses deployment and deployment status webhooks to track deployments. При выполнении задания рабочего процесса, ссылающегося на среду, создается объект развертывания со свойством environment с названием вашей среды. По мере выполнения рабочего процесса создаются объекты состояния развертывания со свойством environment — имя вашей среды, свойством environment_url — URL-адрес среды (если указано в рабочем процессе), и свойством state — состояние задания. For more information, see Документация по приложениям GitHub and События и полезные данные веб-перехватчика.

Choosing a runner

You can run your deployment workflow on GitHub-hosted runners or on self-hosted runners. Traffic from GitHub-hosted runners can come from a wide range of network addresses. If you are deploying to an internal environment and your company restricts external traffic into private networks, GitHub Actions workflows running on GitHub-hosted runners may not be able to communicate with your internal services or resources. To overcome this, you can host your own runners. For more information, see About self-hosted runners and Использование средств выполнения, размещенных в GitHub.

Displaying a status badge

You can use a status badge to display the status of your deployment workflow. Индикатор состояния показывает, что в данный момент рабочий процесс завершается сбоем или передачей. Обычное индикатор состояния добавляется в файл README.md репозитория, но может быть добавлен на любую веб-страницу по вашему желанию. По умолчанию индикаторы показывают состояние ветви по умолчанию. Если в ветвь по умолчанию не выполняется рабочий процесс, отобразится состояние последнего запуска во всех ветвях. Состояние рабочего процесса можно отобразить для определенной ветви или события с помощью branch event параметров запроса в URL-адресе.

For more information, see Добавление эмблемы состояния рабочего процесса.

Finding deployment examples

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

GitHub предлагает шаблоны рабочих процессов развертывания для нескольких популярных служб, таких как веб-приложение Azure. Сведения о начале работы с шаблоном рабочего процесса см. в разделе Использование шаблонов рабочих процессов или полный список шаблонов рабочих процессов развертывания. Вы также можете ознакомиться с более подробными руководствами по конкретным рабочим процессам развертывания, таким как Развертывание Node.js в Службе приложений Azure.

Многие поставщики служб также предлагают действия на GitHub Marketplace для развертывания в своей службе. Полный список см. в разделе GitHub Marketplace.