Инженерная практика
Trunk-based: один полный цикл
Читать про trunk-based development — не то же, что прожить один его полный цикл. Проведите небольшой сервис через всю петлю — вливайте незавершённую работу ежедневно за флагом, сделайте миграцию, которую нельзя выпустить за день, без долгоживущей ветки, держите trunk зелёным под блокирующим гейтом, раскатайте фичу с kill switch и закройте петлю, удалив флаг, — с доказательствами на каждом шаге.
Превратите ментальную модель юнита в воспроизводимый процесс: докажите, что умеете отгружать незавершённую работу на релизопригодный trunk dark, заменять компонент через branch by abstraction, гейтить каждый merge на быстрой зелёной сборке, релизить как измеряемую раскатку и убирать обвязку, чтобы branch debt никогда не вернулся как flag debt.
Возьмите небольшой сервис (свой или стартовый) с реальной фичей для добавления и компонентом для замены и проведите его через один полный цикл trunk-based — ежедневная интеграция за флагами, branch-by-abstraction миграция, быстрый блокирующий CI-гейт, раскатка с метрик-гардами и kill switch, очистка флага, — доказывая каждый шаг историей репозитория, конфигом гейта и метриками до/после.
- История git показывает short-lived branch (каждая влита или удалена за день, три или меньше активных) и незавершённую фичу, вливающуюся в trunk несколькими ежедневными коммитами за выключенным флагом, — никогда не многодневная feature-ветка.
- Branch-by-abstraction миграция видна как последовательность маленьких зелёных коммитов на trunk: интерфейс введён, новая реализация построена dark, абстракция переключена, старый путь и абстракция удалены — с релизопригодным trunk на каждом коммите.
- Конфиг CI-гейта приложен и демонстративно блокирует: намеренно падающий PR показан отвергнутым на гейте, а быстрые проверки завершаются за минуты, пока медленный набор идёт вне критического пути.
- Короткий лог раскатки показывает этапы экспозиции флага с наблюдениями по error rate/latency, плюс продемонстрированный flip kill switch, возвращающий трафик на старый путь без деплоя.
- Проверка flag debt: release flag и мёртвый старый путь удалены в конце, а абзац описания называет, какой trunk-based механизм использован на каждом шаге и почему долгоживущая ветка ни разу не понадобилась.
- Добавьте merge queue (реальный или симулированный) и сконструируйте два PR, каждый из которых зелёный против текущего trunk, но ломается при объединении; покажите, как очередь это ловит, тестируя против проецируемого trunk, и как сбой батча подвергается bisect для выкидывания виновника.
- Добавьте автоматизацию жизненного цикла флагов: отслеживайте возраст флага как возраст ветки и заставьте CI предупреждать или падать, когда release flag переживает заявленный срок, с владельцем у каждого release flag.
- Подключите метрик-гарды к раскатке так, чтобы релиз авто-останавливался (или авто-откатывался), когда error rate или latency пересекают порог, — превращая релиз в замкнутую петлю обратной связи, а не одностороннюю отгрузку.
- Напишите одностраничный runbook процесса: правило ежедневной интеграции, таксономию флагов (release/ops/experiment/permission) с политикой удаления, рецепт branch by abstraction, бюджет скорости гейта и чек-лист раскатки и очистки.
Это петля, которую вы будете гонять в каждой реальной trunk-based команде: интегрировать мелко и часто, чтобы дрейф не копился, отгружать незавершённую работу на релизопригодный trunk dark за флагом, делать всё слишком большое для одного дня через branch by abstraction вместо долгоживущей ветки, держать общий trunk зелёным быстрым блокирующим гейтом (и merge queue на масштабе), релизить как измеряемую раскатку с kill switch и закрывать каждую раскатку удалением флага и мёртвого пути, чтобы branch debt никогда не вернулся как flag debt. Проделав это один раз на небольшом сервисе, вы превращаете продакшен-дисциплину в мышечную память.