Непрерывное развёртывание в промежуточную среду

Введение

Непрерывное развёртывание (CD) — это этап, на котором проверенное программное обеспечение доставляется в среду, где оно может работать.

Снова представьте нашу фабрику программного обеспечения.

CI: робот проверяет продукт на наличие дефектов.
Артефакт: робот упаковывает продукт в коробку.
CD: грузовик доставляет коробку в магазин (на сервер), чтобы клиенты могли ею пользоваться.

В реальном мире развёртывание часто означает обновление работающих систем через SSH, API или специальные механизмы выпуска конкретной платформы. В этой лабораторной работе вы смоделируете такой процесс, но главное — понять путь доставки от протестированного кода до работающей среды.

Это основное различие между CI и CD. CI подтверждает, что изменения в программном обеспечении достаточно надёжны для выпуска, а CD отвечает за контролируемое перемещение этих проверенных изменений в среду.

В этой лабораторной работе вы:

изучите концепцию ручных триггеров (развёртывание по нажатию кнопки);
создадите рабочий процесс развёртывания, имитирующий реальный процесс;
соедините свой «грузовик доставки» (CD) с отделом «контроля качества» (CI).

Предварительные требования

Мы продолжим использовать репозиторий github-actions-basics.

Создайте ручное развёртывание

Иногда не требуется выполнять развёртывание при каждом отправлении кода. Возможно, сначала нужно дождаться одобрения или выполнить развёртывание только тогда, когда вы будете готовы.

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

GitHub Actions позволяет создавать рабочие процессы, которые запускаются только после нажатия кнопки. Для этого используется триггер workflow_dispatch.

Перейдите в каталог рабочего проекта.

cd ~/project
git clone https://github.com/your-username/github-actions-basics.git
cd github-actions-basics

Примечание: замените your-username своим именем пользователя GitHub.

Создайте файл с именем deploy.yml.

touch .github/workflows/deploy.yml

Откройте его в редакторе nano.

nano .github/workflows/deploy.yml

Добавьте следующее содержимое:

name: Deploy to Production

on: workflow_dispatch

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploying
        run: echo "Starting deployment..."

Видите on: workflow_dispatch? Это и есть магическая кнопка.

Сохраните файл, выйдите из nano, а затем отправьте этот файл на GitHub.

git add .
git commit -m "Add manual deployment workflow"
git push

Теперь откройте вкладку Actions на GitHub.

Нажмите Deploy to Production на левой боковой панели.
Вы увидите синюю панель с сообщением «This workflow has a dispatch event trigger.»
Нажмите кнопку Run workflow, а затем зелёную кнопку Run workflow в раскрывающемся списке.

Run workflow

Вы только что вручную запустили конвейер развёртывания!

Смоделируйте этапы развёртывания

Реальные сценарии развёртывания могут быть сложными, но обычно следуют простой схеме:

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

Даже если детали реализации различаются, большинство конвейеров развёртывания сохраняют эту общую структуру: выполнить аутентификацию, получить нужный артефакт и заставить работающую среду использовать его.

Изменим файл deploy.yml, чтобы смоделировать эти этапы. Мы воспользуемся командами echo, чтобы показать, что произошло бы на каждом этапе.

Снова откройте файл.

nano .github/workflows/deploy.yml

Замените раздел jobs этой более подробной моделью:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Mock SSH Connection
        run: echo "Connecting to production server at 192.168.1.1..."

      - name: Pull New Image
        run: |
          echo "Logging into Registry..."
          echo "Pulling image ghcr.io/myname/app:latest..."

      - name: Restart Application
        run: |
          echo "Stopping old container..."
          echo "Starting new container..."
          echo "Deployment Successful!"

Сохраните файл и выйдите из редактора. Отправьте изменения.

git add .
git commit -m "Update deployment steps"
git push

Снова откройте GitHub Actions и вручную запустите рабочий процесс Deploy to Production. Просмотрите журналы. Они выглядят почти как журналы настоящего развёртывания!

Run workflow

Эта техника с «имитацией» действительно полезна. В профессиональной среде мы часто сначала создаём такие рабочие процессы-«каркасы», чтобы согласовать процесс, а уже затем пишем сложный фактический код.

Добавьте проверки безопасности

Сейчас рабочий процесс «развёртывания» полностью отделён от рабочего процесса «тестирования» (CI). Но в реальной жизни нельзя разворачивать неработающий код. Грузовик доставки должен отправляться только после успешного прохождения проверки качества.

Связать рабочие процессы можно с помощью ключевого слова needs, но лучше всего оно работает внутри одного файла. Для отдельных файлов обычно используют управление на уровне процесса: CI запускается при отправке изменений, а CD — при выпуске версии или вручную.

Однако давайте добавим проверку безопасности даже в ручное развёртывание. Будем считать, что выполнять развёртывание следует только при полной уверенности в его готовности.

Откройте deploy.yml.

nano .github/workflows/deploy.yml

Смоделируем защиту environment. Измените steps, добавив паузу.

steps:
  - name: Safety Check
    run: echo " verifying that CI passed..."

  - name: Mock SSH Connection
    run: echo "Connecting to production server at 192.168.1.1..."
  ## ... rest of the file

(Примечание: в настоящей конфигурации Enterprise мы использовали бы функцию GitHub Environments, чтобы до запуска этого задания обеспечить условие «CI должен завершиться успешно». Но для этого требуется настройка за пределами данного файла.)

Пока что сохраните файл, выйдите из редактора и отправьте изменения.

git add .
git commit -m "Add safety check"
git push

В последний раз вручную запустите рабочий процесс.

Итоги

Поздравляем! Вы завершили модуль CICD для GitHub Actions.

В этой заключительной лабораторной работе вы узнали:

Ручные триггеры: как использовать workflow_dispatch для контролируемых развёртываний;
Имитация: как создавать прототип процесса развёртывания с помощью имитируемых этапов;
Общая картина: как связаны CI, артефакты, безопасность и CD.

Вы начали без знаний о GitHub Actions, а теперь у вас есть полностью работоспособный репозиторий с автоматизированными сценариями тестирования, упаковки и развёртывания. Вы готовы начать автоматизацию собственных проектов!