Trunk-based development

Trunk-based development (TBD) - практика, при которой каждый разработчик сливает изменения в единую общую основную ветку как минимум раз в день, работая небольшими порциями и скрывая незавершённую функциональность с помощью feature flag'ов. Это прямая противоположность долгоживущим feature-веткам с отложенным слиянием.

Пол Хаммант (Paul Hammant) на сайте trunkbaseddevelopment.com формализует эту практику. Ограничения, которые он выделяет:

Идеальное время жизни ветки: не больше одного дня; самые мелкие части - около четверти дня.
Ветки, живущие днями или неделями, не имеют отношения к TBD, как бы они ни назывались.
Feature flag'и снимают аргумент "ветка нужна, потому что функциональность ещё не готова".

Данные DORA

Самое убедительное отраслевое подтверждение приводится в отчётах DORA / книге "Accelerate" (Форсгрен, Хамбл, Ким - 23 000 анкет из 2 000+ организаций, а к отчёту 2023 года - более 36 000 специалистов). Высокоэффективные команды:

Держат одновременно менее трёх активных веток.
Ветки живут меньше одного дня.
Не используют code freeze и периоды стабилизации.
Элитные команды, достигающие целевых показателей надёжности, используют TBD в 2,3 раза чаще.

В модели возможностей DORA "тяжеловесные процессы code review" прямо названы препятствием для TBD - они подталкивают разработчиков к крупным порциям изменений и затягиванию слияний. (См. stop-using-pull-requests.)

Отчёт 2023 года добавляет: одно лишь ускорение code review даёт 50% прироста производительности доставки ПО. Механизм прост: именно от скорости ревью зависит, способна ли команда поддерживать ежедневную интеграцию.

Честная оговорка: данные DORA показывают корреляцию, а не причинно-следственную связь. Высокоэффективные команды могут применять TBD просто потому, что они изначально сильнее, а не наоборот. Но согласованность данных опросов за многие годы - сильнейшее доказательство такого масштаба в индустрии.

Почему это трудно

TBD требует предварительных условий, которых у большинства команд нет на момент знакомства с практикой:

Автоматические тесты на каждый коммит - без них "сливать ежедневно" превращается в "ломать trunk ежедневно".
Инфраструктура feature flag'ов - необходима, чтобы доставлять недописанный функционал, не открывая его пользователям.
Быстрое ревью - парная работа, ship-show-ask или неблокирующее непрерывное ревью, поскольку блокирующие асинхронные PR делают ежедневную интеграцию невозможной.
Умение делить работу на мелкие порции - большинство разработчиков привыкли делать коммиты такого размера, что под них обязательно нужен PR; разбивать их мельче - дело привычки, а не смены инструментов.

Инициатива Minimum CD (одним из авторов которой был Джез Хамбл) формулирует категорично: ежедневная интеграция в trunk обязательна. Если ваша команда не интегрирует код в trunk каждый день, вы не занимаетесь continuous integration. Большинство команд, считающих, что у них есть CI, этот тест проваливают.

Место в триаде T*D

Лафорджа (stop-using-pull-requests) объединяет TBD, TDD и парное/ансамблевое программирование в три компонента T*D:

TDD закладывает качество в каждую строчку ещё до её написания.
TBD обеспечивает непрерывность интеграции, крошечный размер порций и постоянную близость к mainline.
Парное/ансамблевое программирование переносит ревью с этапа "после разработки" прямо в процесс написания кода.

Все три подхода усиливают друг друга. TBD без автотестов ломает trunk; TBD без мелких порций изменений порождает конфликты слияния; TBD с блокирующими асинхронными PR логически невозможно (нельзя сливать код ежедневно, если ревью занимает дни).

Связанные страницы

stop-using-pull-requests - более масштабная аргументация, в которой TBD выступает интеграционной составляющей
ship-show-ask - тройная классификация изменений Вильзенаха, делающая TBD совместимым с легковесным опциональным ревью
code-review-knowledge-transfer - истинное назначение ревью, определяющее, может ли асинхронное блокирующее ревью вообще выжить в TBD
pair-programming - командный механизм ревью, позволяющий TBD обходиться без последующих проверочных барьеров
stacked-prs / billjings-git-not-fine - пробелы в рабочих процессах Git'а, которые TBD обходит благодаря отказу от длинных веток