Trunk Based Development

Trunk Based Development (TBD) — это методология разработки программного обеспечения, при которой разработчики как можно чаще интегрируют свои изменения в общую ветку (обычно называемую trunk или master). В отличие от других моделей разработки, таких как Git Flow или Feature Branching, TBD делает акцент на частой интеграции небольших изменений. Такой подход помогает поддерживать актуальность кода и снижать риск интеграционных конфликтов.

Для чего нужен Trunk Based Development?

Уменьшение интеграционных конфликтов

• Частая интеграция кода помогает выявлять и устранять конфликты на ранней стадии, до того как они станут сложными и трудоемкими для решения.

Повышение качества кода

• Постоянное интегрирование изменений способствует более тщательному и регулярному тестированию, что помогает обнаруживать баги и уязвимости быстрее.

Ускорение цикла разработки

• TBD позволяет быстрее выпускать новые версии и фичи благодаря непрерывной интеграции и развертыванию. Это особенно полезно для проектов с частыми релизами и обновлениями.

Упрощение процессов DevOps

• Методология TBD способствует автоматизации процессов сборки, тестирования и развертывания, что упрощает управление релизами и снижает ручной труд.

Поддержание чистоты и актуальности ветки

• Единая ветка позволяет разработчикам всегда работать с актуальной версией кода, избегая устаревших и долго живущих веток, которые могут стать источником проблем.

Заблуждение: Trunk Based Development (TBD) сложен

На самом деле TBD не требует сложной инфраструктуры. Даже примитивные фиче-флаги, реализованные через ресурсные файлы или переменные окружения, могут быть достаточными. Инструменты вроде Kubernetes config maps могут упростить работу, но не являются обязательными.

На начальном этапе высокое покрытие тестами не обязательно. Однако к этому следует стремиться, поскольку медленное ручное тестирование или большое количество ошибок на продакшене со временем начнут серьёзно ограничивать производительность команды. Важно начать покрывать тестами новый код, а не пытаться сразу протестировать весь существующий код.

Что нужно для внедрения TBD

1. общение и командная работа необходимы.
2. если работа над фичей затрагивает множество файлов, может потребоваться упростить уровни абстракции для ускорения код-ревью.
3. пересмотр процессов ревью. Например, требование одобрения от множества занятых коллег может тормозить процесс.
4. принятие TBD требует культурных изменений в команде.

Варианты Trunk Based Development

TBD + Git Tag

В этом варианте релизы происходят исключительно из мастер-ветки. Для релиза ставится тег, позволяющий легко найти нужный коммит в будущем.

Схема хотфикса: В случае срочного хотфикса можно выпустить фикс из транка, однако это рискованно, так как другие изменения могут быть случайно включены.

Требования:

• Высокая автоматизация: автотесты должны выполняться до попадания правок в мастер.
• Использование Feature Toggles и Branch by Abstraction: быстрое включение и выключение правок, гибкое управление функционалом.
• Быстрое откатывание и нахождение проблем: умение быстро откатываться на последнюю стабильную версию.

Стратегия тестирования:

• Merge Request (MR): запуск быстрых и стабильных тестов.
• Master: запуск медленных тестов. В случае проблем остановка всех правок до устранения ошибки.

Недостатки:

• Высокие требования к автоматизации.
• Сложность работы с длительным ручным тестированием.

Пример:

• Проект: мобильное приложение с регулярными обновлениями и улучшениями.
• Описание: команда разработчиков часто вносит изменения в основную ветку. Когда приложение готово к очередному релизу, создается Git Tag для этой версии, что упрощает процесс развертывания и публикации в магазинах приложений.

TBD + Release Branch

В этом подходе релизы осуществляются из специальной релизной ветки, которая удаляется после релиза. Для фиксации ревизий используются теги. Хотфиксы и патчи применяются в релизной ветке, часто через cherry-pick из мастер-ветки.

Стратегия тестирования:

• MR: быстрые и стабильные тесты.
• Master: медленные тесты. Баги должны быть исправлены до создания релизных веток.
• Release Branch: ручные и самые медленные тесты.

Недостатки:

• Более длительные релизы по сравнению с тегами.
• Увеличенное время обратной связи для разработчиков из-за длительных тестовых фаз.

Пример:

• Проект: онлайн-игра с периодическими обновлениями.
• Описание: разработчики интегрируют все изменения в основную ветку в течение всего цикла разработки. Для подготовки очередного обновления игры создается ветка релиза, где проводится тестирование и исправление багов перед тем, как обновление станет доступным пользователям.

Схема хотфикса: ошибки, требующие срочного исправления, сначала исправляются в мастер-ветке, а затем через cherry-pick попадают в релизную ветку. Это позволяет не забывать фиксировать ошибки в мастере и снижает когнитивную нагрузку на разработчиков.

Несколько релизных веток: для ускорения частоты релизов можно использовать несколько релизных веток (канареечный релиз, бета). Каждый новый релиз создается после основного регрессионного тестирования предыдущего и его отправки на бета-тестирование. Это позволяет выпускать релизы с частотой, близкой к основным тестам, не перегружая команду тестирования.

Обсудить статью, узнать больше можно в телеграм канале «Тестировщики нужны».