Environments и ручные апрувы

Ставим «шлагбаум» перед продом — выкладка только с одобрения.

Environment — именованное окружение деплоя (например, staging или production) со своими секретами, переменными и правилами защиты.

Зачем окружения

Окружения решают три задачи разом: хранят отдельные секреты/переменные на стенд, дают защиту (кто и когда может катить) и красиво показывают историю деплоев в интерфейсе GitHub. Это мост между «непрерывной доставкой» и «непрерывным деплоем».

Привязка job к окружению

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://example.com
    steps:
      - run: echo "Катим на прод"

Поле url добавляет в интерфейс ссылку на задеплоенный сайт. Job автоматически получает доступ к секретам и переменным окружения production.

Required reviewers: ручной апрув

В Settings → Environments → production можно включить Required reviewers. Тогда job, привязанный к этому окружению, встаёт на паузу и ждёт, пока назначенный человек нажмёт Approve. Это и есть ручной шаг непрерывной доставки: CI прошёл, артефакт готов, но на прод выпускает человек.

Дополнительные правила защиты окружения:

Правило	Что делает
Required reviewers	требует одобрения 1–6 человек перед запуском job
Wait timer	задержка перед деплоем (окно «передумать»)
Deployment branches	катить на это окружение можно только из разрешённых веток/тегов

Типичная связка двух окружений

Распространённый паттерн: на каждый push в main автоматически катим на staging (без апрува), а на production — только после ручного одобрения. Так быстрые изменения сразу видны на стенде, а прод защищён человеком.

Итог

Environment хранит секреты/переменные стенда и правила защиты.
Required reviewers ставит job на паузу до ручного апрува — основа continuous delivery.
Wait timer и deployment branches дают дополнительный контроль над выкладкой.