Environments, апрувы и откат

Environment — это именованные ворота, а не сервер

В GitHub Actions environment — staging, production — это не машина. Это именованный объект на репозитории, несущий две вещи: protection rules (правила защиты), решающие, когда джоба, целящаяся в него, может запуститься, и секреты и переменные уровня environment, которые резолвятся только внутри джобы, назвавшей этот environment. Джоба подключается одной строкой:

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment: production        # <- привязывает джобу к прод-воротам
    steps:
      - run: ./deploy.sh
        env:
          API_KEY: ${{ secrets.API_KEY }}   # резолвится в *прод*-секрет

В тот миг, когда джоба объявляет environment: production, становятся истинными три вещи. Она не стартует, пока не пройдут protection rules. Её ссылки secrets.* резолвятся в секреты этого environment, перекрывая одноимённые секреты уровня репозитория. И если задан required reviewer, джоба сидит в состоянии Waiting — видимо приостановлена в UI запуска, — пока кто-то с доступом её не апрувнет. Важнейшее: джоба, ждущая апрува, ещё не может прочитать секреты environment: прод-ключ недостижим, пока ворота не открыты. Это и есть свойство, которое ты покупаешь. Утёкший workflow, который никогда не дойдёт до апрувнутой прод-джобы, никогда не увидит прод-учётки.

Protection rules: ревьюеры, таймеры и кто может деплоить

Когда настраиваешь прод-environment, правильный вопрос не «как добавить ворота?», а «что именно эти ворота останавливают?». GitHub даёт environment небольшой, грубоватый набор правил защиты, и сеньор читает их как контроль радиуса поражения.

На планах Free/Pro/Team эти правила работают только для публичных репозиториев; приватным нужен GitHub Team или Enterprise. И кусается одна особенность дизайна: protection rules цепляются к джобе, а не к workflow. Если три джобы целятся в production, ревьюер апрувит три раза — быстрейшая дорога к усталости от апрувов.

Модель promotion: staging авто, production на паузе

Стандартная форма — единый пайплайн build → staging → production, где staging автоматический, а production — гейтированная promotion того же артефакта. Ты собираешь один раз, выкатываешь ровно эту сборку на staging без ворот, а прод-джоба — зависящая от staging через needs: — встаёт на паузу у своих ворот, пока ревьюер не продвинет её. Добавь concurrency:, чтобы два пуша не гонялись в один environment.

concurrency:
  group: deploy-${{ github.ref }}   # один прод-деплой за раз на ref
  cancel-in-progress: false         # дай текущему деплою доехать, следующий — в очередь

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging            # нет required reviewer -> запускается автоматически
    steps:
      - run: ./deploy.sh staging

  deploy-production:
    needs: deploy-staging           # продвигаем ту же сборку
    runs-on: ubuntu-latest
    environment:
      name: production              # required reviewers заданы в настройках репо
      url: https://app.example.com
    steps:
      - run: ./deploy.sh production

concurrency здесь — тихий герой. Без него два мёржа в main с разницей в минуты запускают два прод-деплоя, которые переплетаются — старый артефакт может приземлиться после нового и тихо победить. Ключ группы — любая строка; cancel-in-progress: false даёт безопасный дефолт «доделай текущий деплой, потом следующий», максимум один в работе и один в ожидании.

Когда ломается: откат vs roll-forward

Плохой деплой уехал. Что теперь? Два хода. Откат (rollback): переразвернуть предыдущий заведомо рабочий артефакт — быстро и тривиально, когда пайплайн умеет переподнять деплой-джобу прошлой сборки. Roll-forward (он же fix-forward): пишешь фикс, прогоняешь через тот же гейтированный пайплайн, выкатываешь новую версию поверх.

Откат — инстинкт, но у него острый край: как только деплой прогнал миграцию базы, переразвёртывание старого кода не откатывает схему. Старый бинарник теперь встречает схему, под которую его не писали, — удалённую колонку, переименованную таблицу, бэкфилленный enum. Гайд самого GitLab прямолинеен: нет гарантии, что приложение и база откатятся вместе, так что самая безопасная стратегия — обычно roll-forward. Откатывай код, продвигай вперёд данные. Если миграции аддитивны и обратно совместимы (дисциплина expand/contract), откат кода безопасен — старый код по-прежнему работает с новой схемой. Если они деструктивны, откат может испортить или потерять данные, и форвард-фикс — компенсирующая миграция плюс исправленный код — единственный честный ход.