Окружения и гейты: required reviewers, wait-таймеры и защита веток

Окружение — ограниченная, гейтированная граница

GitHub Environment (production, staging) — две вещи разом: область для секретов и набор protection rules вокруг любого джоба, что нацелен на него. Джоб подписывается через environment: production, и в этот момент случаются три вещи. Первое: джоб получает доступ к секретам, ограниченным окружением — прод-деплой-токен живёт на окружении, а не свободно в репо, так что лишь джоб, успешно вошедший в production, может его увидеть. Второе: ран паузится до старта джоба, пока не удовлетворено каждое protection rule. Третье: деплой записывается на окружение, давая аудит-след кто-что-когда задеплоил. Инцидент из Hook невозможен в момент, когда прод-токен ограничен окружением, а окружение гейтировано, потому что больше нет пути от «триггернуть workflow» к «держать прод-кред», что не проходит через правила.

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment: production      # ограничивает секреты + триггерит protection rules
    steps:
      - run: ./deploy.sh
        env:
          TOKEN: ${{ secrets.PROD_DEPLOY_TOKEN }}   # читаем лишь внутри `production`

Три protection rules

Каждое правило закрывает свой вид дыры. Читая инцидент из Hook, обрати внимание, какое именно правило его бы остановило — и заметь, что убирая любое из трёх, ты воссоздаёшь версию той же дыры. Правила окружения — то, что конвертирует «джоб, что может деплоить» в «управляемый деплой»:

• Required reviewers (обязательные ревьюеры): ран блокируется, пока именованный человек или команда не одобрит деплой в UI GitHub. Критически, одобрение отдельно от код-ревью — оно гейтит акт деплоя этого рана в это окружение, и ревьюер, который и есть деплоер, обычно не может само-одобрить, так что отгрузка всегда требует второго человека. Это правило обошёл push в 2 ночи.
• Wait timer (таймер ожидания): настраиваемая задержка (0–43 200 минут, т.е. до 30 дней), вставленная перед запуском джоба после одобрения. Короткий таймер — скажем, 10 минут — создаёт намеренное окно выдержки/отмены: очевидно-плохой релиз можно отменить до касания production, а canary перед ним имеет время отрапортовать.
• Deployment branches (ограничение веток деплоя): ограничивают, какие ветки могут деплоить в окружение — обычно лишь main (или паттерн релизного тега). В сочетании с защитой ветки на main (обязательное PR-ревью, обязательные status checks, без прямых push) это гарантирует, что единственный код, что может достичь production — это код, отревьюенный и прошедший CI на защищённой ветке. Hotfix-ветка из Hook была бы отвергнута сразу.

Вместе три правила означают, что production не просто запаролен — он структурно недостижим, если только качество кода, человеческое суждение и таймер не прошли все три проверки. Убери любое — код прямого push, само-одобренный деплой, мгновенный взрыв — и открывается дыра, ровно та, в которую провалился инцидент.

Required reviewers vs защита веток: два разных гейта

Частая путаница — считать защиту ветки и required reviewers избыточными. Они стерегут разное. Защита ветки управляет тем, какой код допущен в main — она о надёжности артефакта и срабатывает на момент merge. Required reviewers на окружении управляет тем, может ли этот конкретный ран деплоить сейчас — она об акте релиза и срабатывает на момент деплоя. Изменение может быть идеально отревьюено и смержено (защита ветки удовлетворена) и всё равно требовать намеренного, отдельно-одобренного решения толкнуть его в production в рабочие часы с кем-то наблюдающим (ревьюер окружения удовлетворён). Тебе нужны оба, потому что они падают по-разному: одна защита ветки даёт любому зелёному коммиту main авто-деплоиться без человека в петле на момент релиза; одно ревью окружения даёт человеку одобрить деплой кода, что никогда не ревьюился. Wait-таймер затем добавляет время к человеческому гейту, а deployment-branch-правила связывают двоих, гарантируя, что одобряемый ран реально происходит из защищённой ветки.