Trunk Based Development

TBD vs Feature branches

‍

В TBD фичи поделены между разработчиками, каждый делает небольшую, независимую, измеримую часть. У фич есть отдельные ветки, но они не долгоживущие — срок жизни не более нескольких часов. Релизы частые, маркированные — кто и что добавил.

Что дает TBD

Контроль качества и работоспособности кода становится более прозрачным, откатить нерабочие изменения можно проще и безопаснее.

Обновление проекта ритмичное и всегда живое.

Don’t branch — важнейший принцип!

Что мешает внедрить TBD

• Долгий и излишне усложненный процесс code review.

• Code review отделено от работы над кодом. Между написанием кода и обратной связью проходит несколько дней. Разработчик теряет фокус, это ухудшает производительность.

• До коммита код не проходит автотесты. Баги не вычищены, это мешает сохранять работоспособность всего проекта.

‍

Как измерять

Количество активных бранчей в репозитории

Что измеряем?

Сколько активных бранчей приложения существует параллельно? Число нужно довести до целевого.

Цель

≤3 активных ветки/

Периоды «заморозки» кода

Что измеряем?

Сколько «заморозок» кода случается за единицу времени и сколько длится каждая.

Цель

Нет заморозки кода.

Частота слияния бранчей и транка

Что измеряем?

Либо используйте бинарный тест (да/нет) для каждой ветки, либо ежедневно измеряйте процент объединившихся веток.

Цель

Ветки объединяются как минимум раз в день.

Время на одобрение кода

Что измеряем?

Если code review проводится асинхронно, измерьте среднюю длительность одобрения изменений в коде. Особое внимание уделите тем запросам на изменения, которые занимают намного больше времени.

Цель

Code review должно стать частью процесса разработки

‍

Как улучшать

• Создать группу менторов и адвокатов методики, которые помогут всем разработчикам перейти к TBD.

• Делить работу на небольшие пакеты.

• Выполнять code review синхронно.

• Внедрить автотестирование кода.

• Использовать быстрые сборки.

‍

Подробнее о Trunk Based Development

‍