Развертывание с помощью 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 выполняет развертывание в среде, эта среда отображается на главной странице репозитория. Вы можете использовать среды, чтобы требовать утверждения для продолжения задания, ограничить, какие ветви могут активировать рабочий процесс, воротные развертывания с помощью настраиваемых правил защиты развертывания или ограничить доступ к секретам. Дополнительные сведения о создании сред см. в разделе Управление средами для развертывания.

Среды можно настроить с помощью правил защиты и секретов. Если задание рабочего процесса ссылается на среду, это задание не будет запускаться до тех пор, пока не будут выполнены все правила защиты среды. Задание также не может получить доступ к секретам, определенным в среде, пока не будут передаваться все правила защиты развертывания. Дополнительные сведения см. в разделе "Использование правил защиты от пользовательского развертывания" в этой статье.

Использование параллелизма

Параллелизм обеспечивает одновременное выполнение только одного задания или процесса с использованием одной группы параллелизма. Можно использовать параллельность так, чтобы в среде было максимум одно развертывание в процессе и одно ожидающее развертывание одновременно. Дополнительные сведения о параллелизме см. в разделе Управление параллелизмом рабочих процессов и заданий.

Например, если выполняется следующий рабочий процесс, он будет приостановлен с состоянием pending, в случае выполнения задания или рабочего процесса, использующего группу параллелизма production. Кроме этого, будет отменено любое задание или рабочий процесс, использующий группу параллелизма 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 рабочий процесс внедряется в окружение, среда отображается на главной странице репозитория. Дополнительные сведения о просмотре развертываний в средах см. в разделе Просмотр журнала развертывания.

Мониторинг выполнения рабочего процесса

Во время каждого выполнения рабочего процесса создается граф в режиме реального времени, иллюстрирующий ход выполнения. Этот граф можно использовать для мониторинга и отладки развертываний. Дополнительные сведения см. в разделе Использование графа визуализации.

Кроме этого, вы можете просматривать журналы каждого выполнения рабочего процесса, а также журнал запусков рабочего процесса. Дополнительные сведения см. в разделе Просмотр журнала выполнения рабочего процесса.

Использование необходимых проверок в рабочих процессах

Задания, ссылающиеся на среду, настроенную с обязательными рецензентами, будут ожидать утверждения перед запуском. Во время ожидания утверждения, оно находится в состоянии "Ожидание". Если задание не утверждено в течение 30 дней, оно автоматически завершится ошибкой.

Дополнительные сведения о средах и необходимых утверждениях см. в разделе Управление средами для развертывания. Сведения о проверке развертываний с помощью REST API см. в разделе Конечные точки REST API для выполнения рабочих процессов.

Использование пользовательских правил защиты развертывания

Примечание.

Пользовательские правила защиты развертывания в настоящее время находятся в Публичный предварительный просмотр и подвергаются изменению.

Вы можете включить собственные правила защиты для шлюза развертываний с помощью сторонних служб. Например, можно использовать такие службы, как Datadog, Honeycomb и ServiceNow, чтобы предоставить автоматические утверждения для развертываний в GitHub.

Правила защиты от пользовательского развертывания основаны GitHub Apps на вебхуках и обратных вызовах. Утверждение или отклонение задания рабочего процесса основано на использовании deployment_protection_rule веб-перехватчика. Дополнительные сведения см. в разделе События и полезные данные веб-перехватчика и утверждение или отклонение развертываний.

После создания настраиваемого правила защиты развертывания и его установки в репозитории настраиваемое правило защиты развертывания будет автоматически доступно для всех сред в репозитории.

Развертывания в среде могут быть утверждены или отклонены на основе условий, определенных в любой внешней службе, такой как утвержденный билет в системе УПРАВЛЕНИЯ ИТ-службами (ITSM), уязвимый результат сканирования на зависимости или стабильные метрики работоспособности облачного ресурса. Решение об утверждении или отклонении развертываний осуществляется по усмотрению интеграции стороннего приложения и условий, которые вы определяете в них. Ниже приведены несколько вариантов использования, для которых можно создать правило защиты развертывания.

ITSM & Security Operations: вы можете проверить готовность службы, проверяя качество, безопасность и соответствие процессам, которые проверяют готовность к развертыванию.
Системы наблюдения: вы можете проконсультироваться с системами мониторинга или наблюдаемости (системы управления производительностью активов и агрегатами журналов, системами проверки работоспособности облачных ресурсов и т. д.) для проверки готовности к безопасности и развертыванию.
Средства качества кода и тестирования: вы можете проверить наличие автоматических тестов на сборках CI, которые необходимо развернуть в среде.

Кроме того, можно написать собственные правила защиты для любого из приведенных выше вариантов использования или определить любую пользовательскую логику для безопасного утверждения или отклонения развертываний из предварительной среды в рабочие среды.

Отслеживание развертываний с помощью приложений

Вы также можете создать приложение, использующее веб-перехватчики развертываний и их состояния для отслеживания развертываний. При выполнении задания рабочего процесса, ссылающегося на среду, создается объект развертывания со свойством environment с названием вашей среды. По мере выполнения рабочего процесса создаются объекты состояния развертывания со свойством environment — имя вашей среды, свойством environment_url — URL-адрес среды (если указано в рабочем процессе), и свойством state — состояние задания. Для получения дополнительной информации смотрите Документация приложений GitHub и События и полезные данные веб-перехватчика.

Выбор средства выполнения тестов

Вы можете запускать процесс развертывания на GitHub-hosted runners или на самостоятельных раннерах. Трафик от GitHub-hosted runners может поступать с широкого диапазона сетевых адресов. Если вы внедряете в внутреннюю среду и ваша компания ограничивает внешний трафик в частные сети, GitHub Actions рабочие процессы, работающие на GitHub-hosted runners, могут не иметь возможности взаимодействовать с вашими внутренними сервисами или ресурсами. Чтобы решить эту проблему, вы можете разместить собственные средства выполнения тестов. Дополнительные сведения см. в разделе [AUTOTITLE и Локальные средства выполнения тестов](/actions/using-github-hosted-runners/about-github-hosted-runners).

Отображение эмблемы состояния

Для отображения состояния рабочего процесса развертывания можно использовать эмблему состояния. Индикатор состояния показывает, что в данный момент рабочий процесс завершается сбоем или передачей. Обычное индикатор состояния добавляется в файл README.md репозитория, но может быть добавлен на любую веб-страницу по вашему желанию. По умолчанию индикаторы показывают состояние ветви по умолчанию. Если в ветвь по умолчанию не выполняется рабочий процесс, отобразится состояние последнего запуска во всех ветвях. Состояние рабочего процесса можно отобразить для определенной ветви или события с помощью branch event параметров запроса в URL-адресе.

Дополнительные сведения см. в разделе Добавление эмблемы состояния рабочего процесса.

Поиск примеров развертывания

В этой статье были продемонстрированы особенности, GitHub Actions которые вы можете добавить в свои рабочие процессы развертывания.

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

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