Team Policy: What Merges Automatically
Change classes by blast radius: what merges automatically on green CI, where a human is mandatory, how to codify the policy with CODEOWNERS and rulesets, and which metrics to steer it by.
Lesson content is currently available in Russian.
What you will learn
- →Классифицировать изменения по уровням риска и назначать каждому уровню свои требования к ревью.
- →Оформлять политику технически: CODEOWNERS, rulesets, обязательные проверки и авто-мерж GitHub.
- →Управлять политикой по метрикам: escape rate, доля возвратов и время до мержа по уровням.
Зачем формальная политика, когда «и так понятно»
Пока PR пять в неделю, команда обходится неписаными нормами: все примерно понимают, что миграцию смотрят вдвоём, а опечатку в README мержат сразу. Агенты ломают это равновесие объёмом: при пятидесяти PR в неделю неписаная норма превращается в лотерею — один ревьюер неделю вычитывает правку документации, другой апрувит миграцию БД по диагонали, потому что «CI же зелёный». Без явной политики команда получает худшее из двух миров: медленный конвейер и случайное качество.
Основа политики — классификация изменений по радиусу поражения: что будет, если этот дифф окажется дефектным? Практичная шкала из четырёх уровней. Tier 0 — изменения, не влияющие на поведение: документация, комментарии, только-тесты (добавление, не изменение ожиданий). Tier 1 — обратимые изменения с узким радиусом: внутренний код за фича-флагом, патч-обновления зависимостей, конфиги дев-окружения. Tier 2 — бизнес-логика: пользовательские сценарии, интеграции, всё, что заметно снаружи, но откатывается обычным revert. Tier 3 — необратимое и системное: миграции схемы, авторизация и платежи, публичные API-контракты, инфраструктура, секреты, CI-конвейер.
Важно: уровень определяется по самому рискованному файлу диффа. PR «фича плюс маленькая миграция» — это tier 3 целиком; именно поэтому политика подталкивает агентов (и людей) резать изменения на PR одного уровня. Классификация по путям файлов автоматизируется — glob-паттерны в CI размечают PR лейблом уровня без участия человека.
Матрица решений и механика GitHub
Каждому уровню — свой минимальный достаточный процесс:
- Tier 0 — зелёный CI + агент-ревью без критических находок → авто-мерж. Человек не участвует.
- Tier 1 — зелёный CI + агент-ревью + один человек «по отчёту»: читает находки ревьюера и diff --stat, апрув за минуты, не часы.
- Tier 2 — полное ревью одним человеком по протоколу трёх проходов; агент-ревью служит картой внимания.
- Tier 3 — два человека, один из которых владелец зоны (security для auth, DBA/старший для миграций); авто-мерж запрещён технически, а не договорённостью.
Механика GitHub, которой это оформляется:
- CODEOWNERS — файлы зон tier 3 закреплены за владельцами; их ревью становится обязательным автоматически;
- Rulesets на защищённые ветки — обязательные status checks (тесты, SAST, агент-ревью), required approvals, запрет force-push; для путей tier 3 — повышенные требования;
- Auto-merge — включается на PR и срабатывает сам, когда все обязательные проверки зелёные: это и есть техническая реализация tier 0/1;
- Dependabot + автомерж патчей — отдельный workflow апрувит и мержит patch-обновления зависимостей после зелёного CI; minor и major идут по tier 2.
Принцип оформления: политика, живущая в голове тимлида, не масштабируется; политика в rulesets исполняется без напоминаний. Всё, что можно закрепить настройкой репозитория, закрепляется настройкой; документ с политикой (короткий REVIEW_POLICY.md в корне) объясняет «почему», а не подменяет «как».
Провенанс и ответственность
Политика авто-мержа работает только вместе с прослеживаемостью: в любой момент должно быть видно, какой код написан агентом, по чьему запросу и кто за него отвечает.
Провенанс оформляется тремя слоями. Лейбл на PR (ai-generated, ai-assisted) — для маршрутизации и метрик; проставляется автоматически конвейером, который создал PR. Трейлеры в коммитах — стандартный для Git способ машиночитаемых метаданных: строка вида Generated-by с именем агента и модели в footer коммита переживает squash и попадает в blame. Отчёт агента-ревьюера как артефакт PR — при разборе инцидента видно, что было найдено до мержа и какое решение принял человек.
Правило ответственности формулируется жёстко: за AI-PR отвечает человек, который запустил агента. Не «модель ошиблась», а «я смержил» — иначе авто-мерж превращается в машину по производству ничьих багов. Практическое следствие: у каждого автономного агента есть владелец-человек, чьё имя стоит в PR как assignee, и лимит — сколько PR этот человек реально способен курировать. Двадцать PR в день на одного владельца — это не автоматизация, это отказ от ответственности с дополнительными шагами.
Последний элемент — протокол отката политики. Дефект, дошедший до main через авто-мерж, автоматически понижает зону: пути, где случился инцидент, временно переводятся на уровень выше (tier 0 → tier 1, tier 1 → tier 2) до разбора. Разбор отвечает на один вопрос: какой автоматической проверки не хватило, чтобы этот дефект не прошёл? Ответ становится новым правилом SAST, тестом или Semgrep-паттерном — и зона возвращается на прежний уровень. Так политика учится на инцидентах вместо того, чтобы навсегда закручиваться от страха.
Метрики и раскрутка политики
Политика — не документ, а контур управления с обратной связью. Четыре метрики, по которым она настраивается:
- Escape rate по уровням — доля дефектов, дошедших до main, в разрезе tier. Главный показатель: если tier 1 месяцами держит escape rate на уровне tier 2 с человеческим ревью, значит человеческое ревью на tier 1 не добавляло ценности — можно расширять авто-мерж. Рост escape rate — сигнал сжать.
- Revert rate — доля откаченных PR среди авто-смерженных против прошедших ревью. Прямое измерение того, что пропускает автоматика.
- Time-to-merge по уровням — если tier 0 ждёт мержа сутки, политика на бумаге, а не в rulesets; если tier 3 мержится за десять минут — кто-то обходит процесс.
- Нагрузка на ревьюеров — PR на человека в неделю. Метрика ёмкости: политика обязана держать её в пределах, при которых ревью остаётся честным, а не превращается в конвейерный апрув.
Стратегия внедрения — храповик от консервативного: стартуйте с авто-мержем только tier 0, всё остальное — через человека. Каждые две-четыре недели смотрите метрики и расширяйте автоматику на одну ступень там, где данные это оправдывают. Обратное движение («начнём смело, ужесточим после первого пожара») стоит дороже: один громкий инцидент авто-мержа — и команда откатывается к тотальному ручному ревью, потеряв доверие к самой идее.
Итоговая проверка зрелости политики: новый человек в команде может за десять минут по REVIEW_POLICY.md и настройкам репозитория понять, что случится с любым его PR — и ни один пункт этого пути не зависит от того, кто сегодня дежурит.
Practice
Политика ревью для своего репозитория
Классифицируйте пути своего проекта по четырём уровням риска (glob-паттерны), напишите REVIEW_POLICY.md на одну страницу с матрицей «уровень → требования» и оформите технически: CODEOWNERS для tier 3, ruleset с обязательными проверками, авто-мерж для tier 0 и workflow автомержа патчей Dependabot.
Deliverable
REVIEW_POLICY.md, файл CODEOWNERS, скриншот или экспорт ruleset и один демонстрационный PR каждого уровня, прошедший свой маршрут: tier 0 смержился сам, tier 3 потребовал владельца зоны.
Checkpoint
Защитите свою матрицу авто-мержа перед скептиком-безопасником: почему tier 0/1 безопасно мержить без человека, что технически мешает агенту смержить миграцию и как политика отреагирует на первый пропущенный дефект.
- ✓ Уровни определены по радиусу поражения с правилом «уровень PR равен уровню самого рискованного файла».
- ✓ Названы технические барьеры, а не договорённости: rulesets, CODEOWNERS, обязательные status checks, запрет авто-мержа для путей tier 3.
- ✓ Описан контур обратной связи: escape rate и revert rate по уровням, протокол временного понижения зоны после инцидента и превращение разбора в новую автоматическую проверку.
Check yourself
Sources