Статьи

Вы всё ещё пользуетесь Gitflow? Обзор TBD

Если вы разработчик программного обеспечения или работаете в сфере управления версиями исходного кода, скорее всего, вы сталкивались с термином Gitflow. Это процесс работы с ветками в системе контроля версий Git, популяризированный Винсентом Дриссеном в 2010 году. Многие компании и индивидуальные разработчики успешно применяют эту стратегию уже много лет. Но сейчас, в эпоху быстрых изменений и требований к продуктовой разработке, возникает вопрос: "Стоит ли продолжать использовать Gitflow или пора перейти на что-то новое?"

Одной из альтернатив является Trunk-Based Development (TBD). В этой статье мы рассмотрим, что такое Gitflow и TBD, и как они соотносятся между собой.

Что такое Gitflow?

Gitflow — это строгая модель управления ветками. Она включает:

- Основную ветку (main/master), где всегда хранится стабильная версия продукта.
- Ветку разработки (develop), где ведётся активная разработка и слияние новых фич.
- Фичевые ветки (feature branches), которые создаются для работы над новыми функциональностями.
- Релизные ветки (release branches) для подготовки к выпуску новых версий.
- Исправляющие ветки, hotfix branches, для быстрого исправления критичных ошибок в основной ветке; а также bugfix branches, которые создаются для исправления обнаруженных ошибок в ветке разработки (develop).

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

Что такое Trunk-Based Development (TBD)?

Trunk-Based Development (TBD) — это более упрощённый и гибкий процесс работы с ветками, при котором разработки происходят преимущественно в одной основной ветке (trunk/master). Ключевые моменты TBD:

- Разработчики часто добавляют новые коммиты в основную ветку (trunk).
- Новые фичи и исправления интегрируются быстрее.
- Минимум долгоживущих веток. Фичевые ветки существуют короткое время и сливаются обратно в trunk сразу после завершения работы.

TBD идеально вписывается в современные практики Continuous Integration (CI) и Continuous Deployment (CD), позволяя быстро и безопасно доставлять новые функции и исправления пользователям.

Gitflow vs TBD: Плюсы и Минусы

Gitflow
Плюсы:

- Четкое разграничение этапов разработки.

- Легче отслеживать статус проекта и текущие задачи.

- Полезно для крупных проектов с долгим жизненным циклом.

Минусы:

- Сложность управления ветками.

- Более медленное интегрирование кода.

- Требует больших усилий на синхронизацию и мержинг веток.


Trunk-Based Development
Плюсы:

- Ускоряет доставку новых функций и исправлений.

- Упрощает процесс управления ветками.

- Идеально для Agile и DevOps команд.

- Небольшие код ревью.

- Использование нового кода в нескольких фичах.

- Возможность быстро включать и выключать фичи.

Минусы:

- Требует дисциплины и зрелости разработчиков.

- Высокий риск конфликтов, если команда неосторожно работает с основной веткой.

- Может быть сложнее отслеживать статус конкретных фич.

- Необходима хорошая экспертиза в DevOps для FF.

- Необходимо большое покрытие тестами.

Вывод

Если ваш проект представляет собой большой продукт с долгим жизненным циклом и строгими требованиями к управлению версиями, Gitflow может оказаться лучшим выбором. Однако, если ваша команда работает в среде Agile и требует быстрой и бесшовной интеграции, то Trunk-Based Development может предложить большую гибкость и скорость.

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

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

Хотите узнать больше? Изучите другие статьи из разделов:
Основы и старт в IT DevOps