Ветка о двух концах. Как долететь на орлах вместо того, чтобы идти пешком

Что такое Trunk Based Development и фича-флаг

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

В этой статье мы поговорим:▹О стратегиях ветвления в Git и методах использования Trunk Based Development при разработке программного обеспечения▹Рассмотрим, что такое фича-флаг, и как он может использоваться вместе с Trunk Based Development▹А в конце я поделюсь опытом нашей команды и отзывами счастливых пользователей, убедившихся в преимуществах использования этих методов

Кто я такой и почему вам тут вещаю? Меня зовут Иван, я frontend-разработчик DexSys. Делаю красивые интерфейсы в проекте UFO Pro, топлю за микрофронтенды и помогаю разработчикам развиваться.

Эта статья может быть полезна разработчикам, тестировщикам, менеджерам проектов и другим профессионалам, связанным с созданием программного обеспечения. Кроме того, она может быть полезна студентам и всем интересующимся современными методами и подходами к разработке. В частности, статья может быть интересна тем, кто хочет узнать о Trunk Based Development, фича-флагах, и их применении в процессе разработки.

В мире современной разработки выбор правильной стратегии ветвления является важной частью процесса. Так что же это такое, и какое влияние эти стратегии оказывают на процесс разработки?

Существует множество различных способов ветвления, которые можно использовать при работе с Git. В этой статье мы рассмотрим три наиболее распространенных способа ветвления: Git Flow, GitHub Flow и Trunk Based Development.

Git Flow и GitHub Flow являются наиболее популярными ветвящимися стратегиями в коммерческой разработке. Trunk Based Development является несколько более рискованным подходом, поскольку он не предусматривает постоянных веток. Рассмотрим их подробнее:

Git Flow - это методология ведения разработки с использованием системы контроля версий Git. Она была разработана Винсентом Дриессеном и опубликована в 2010 году.

Git Flow предлагает структуру ветвления репозитория Git, которая позволяет эффективно управлять процессом разработки, отделяя стабильные версии от версий, находящихся в разработке. Методология основана на использовании двух основных веток: master и develop.

Ветка master содержит только стабильные версии продукта, которые готовы к выпуску. Ветка develop используется для разработки новых функций и исправления ошибок. Кроме того, Git Flow предлагает использовать дополнительные ветки для различных типов задач, таких как feature - для разработки новых функций, release - для подготовки к выпуску новой версии, hotfix - для исправления критических ошибок в текущей версии, и т.д.

Git Flow также определяет процедуры работы с каждой из веток, например, процедуру слияния ветки feature в develop или процедуру создания новой версии из ветки release.

GitHub Flow - это методология ведения разработки с использованием системы контроля версий Git и платформы GitHub.

GitHub Flow предлагает использовать только одну основную ветку - master. Все изменения в коде вносятся через создание новых веток, которые называются feature-ветками. Каждая feature-ветка создается для решения конкретной задачи или добавления новой функции. После завершения работы над задачей в feature-ветке происходит запрос на слияние, pull request, в основную ветку master.

GitHub Flow также предлагает использовать дополнительные инструменты GitHub, такие как Issues и Projects, для управления задачами и проектами.

Эта стратегия ветвления ориентирована на непрерывную интеграцию и доставку (CI/CD), что позволяет быстрее и безопаснее выпускать новые версии продукта.

В целом, GitHub Flow является более простой и гибкой методологией, чем Git Flow, и может быть особенно полезной для небольших команд или проектов.

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

Для крупных проектов предлагается использовать Scaled Trunk Based Development. Главным отличием является то, что коммиты делаются не напрямую в trunk, для этого используются короткоживущие feature-ветки.

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

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

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

Преимущества Trunk Based Development:

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

Хотя Trunk Based Development может быть эффективным методом для управления процессом разработки, он также имеет свои недостатки:

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

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

• Кроме того, Trunk Based Development не позволяет экспериментировать с новой функциональностью в отдельных ветках, потому что это может оказать негативное влияние на основную ветку и другие компоненты. Для решения этой проблемы можно использовать фича-флаги, чтобы временно включить или отключить опасные или еще не полностью разработанные функции, и избежать возможных проблем в основной ветке.

Если сложно, то фича-флаги (feature flags, feature toggles) — это инструмент разработки, который включает и выключает выбранные фичи в рантайме без развертывания нового кода.

Если просто, то это if в коде.

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

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

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

• DevCycle
• Flagsmith
• Unleash

Если нужно что-то попроще, или хочется лишь протестировать подход, то подойдут следующие способы:

• Старые добрые env-переменные
• Простой, как палка, json-файл
• Свой сервис с простой API

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

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

Что у нас было раньше?

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

Почему мы решили измениться?

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

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

Соответственно, все эти проблемы выливались в финансовые потери, ведь время - деньги.

Подготовка и переходный этап, инструкция:

• Мержим все что есть в одну ветку
• Делаем резервную копию, на случай, если что-то пойдет не так
• Настраиваем репозиторий: в нашем случае это squash вместо merge commit, сливаем только через pull-реквест, выставляем обязательных ревьюеров
• Проводим инструктаж для разработчиков
• Кодим

Отзывы пользователей:

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

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

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

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

Автор статьи: Иван, frontend-разработчик DexSys.