В предыдущих статьях мы уже затрагивали тему подходов при работе с git и подробно рассматривали метод Gitflow и Feature Branch Workflow как основу коллективной работы над кодом. Напомним, что основной идеей в Gitflow является создание feature-веток – для разработки одного нового функционала создается отдельная ветка, которая вливается в ветку develop, когда работа над функциалом окончена. При этом нередко возникают сложности с разрешением конфликтов, сломаными сборками.
В данной статье мы рассмотрим альтернативный подход для контроля версий исходного кода – разработка на основе главной ветки, или Trunk-Based Development. В ее основе лежит такая модель ветвления, в которой разработчики совместно работают над кодом в одной ветке, называемой «главной» (или master в терминологии Git). При этом второстепенные feature-ветки также могут создаваться, но они имеют короткий срок жизни. Этот подход прочно занимает свои позиции наряду с другими документированными методами разработки в долгосрочных ветках и позволяет разработчикам избежать сложностей связанных со слиянием веток. Словосочетание «главная ветка» (от англ. “trunk” - ствол) несет в себе идею растущего дерева, у которого самой толстой и самой длинной частью является именно ствол, а не ветви, которые расходятся от него и имеют более ограниченную длину.
После того, как разработчики долго используют Gitflow, данный подход может выглядеть наивным и примитивным, однако, для проектных команд, которые сфокусированы и стремятся продвигаться максимально быстро, именно такой подход может дать лучшие результаты.
При использовании разработки на основе главной ветки процессы непрерывной интеграции и непрерывной поставки являются критически необходимыми, так как позволяют участникам команды прогнозируемо интегрировать свои наработки в основной код с обеспечением гарантии качества результата.
Один из приверженцев подхода TBD, выступая на конференции JAX, говорил, что у них в команде есть большая красная сирена, которая воет каждый раз, когда интеграция неуспешно. Это мотивирует участников команды делать изменения такими компактными, чтобы шанс их интеграции без ошибок был максимально выскоким.
Данная статья является переводом оригинальной статьи с официального сайта подхода TBD – trunkbaseddevelopment.com.
Участники команды вносят изменения в главную ветку несколько раз в день, тем самым выполняется основное требование непрерывной интеграции, согласно которому все члены команды обязуются делать комиты в главную ветку не реже одного раза в сутки. Это гарантирует доступность кодовой базы по запросу и позволяет осуществлять непрерывную поставку.
Базовые правила разработки на основе главной ветки
Trunk-Based Development можно использовать вместо моделей ветвления GitFlow и других моделей, основанных на использовании нескольких долгосрочных веток. В малых выскоквалифицированных командах участники могут делать отправку кода в сразу в главную ветку, другие команды могут сделать выбор работаты через пул-реквесты. Важное условие в том, что feature-ветки существуют недолго и в одной ветке работает один человек.
Особенности подхода
-
В зависимости от количества человек в команде и частоты отправок, для проверки кода и сборок (CI) используются краткосрочные feature-ветки. Такие feature-ветки позволяют разработчикам активно и непрерывно делать анализ кода вливаемых изменений до того, как они будут интегрированы в главную ветку. Небольшие команды могут делать отправку кода напрямую в главную ветку.
-
В зависимости от предполагаемой частоты релизов можно использовать ветки релизов, которые в нужный момент создаются от главной ветки, «замораживаются» перед релизом (в них не ведется никакой активности), и удаляются через некоторое время после релиза. В альтернативном подходе ветки релиза могут отсутствовать, если команда далает релиз из главной ветки и для исправления ошибок выбирает стратегию «исправления вперед». Создание релиза из главной ветки также подходит для высокопроизводительных команд.
-
Участникам команды следует владеть техникой Branch by Abstraction для постепенного длительного внесения изменений в код, и в повседневной разработке использовать флаги функций (feature flags или feature toggles), чтобы обеспечить порядок релизов. Подробнее читайте раздел “Одновременная разработка последовательных релизов”.
-
Если в команде задействовано несколько разработчиков, следует использовать сервер сборки, чтобы иметь уверенность в том, что отправка нового кода не ломает сборку после добавления в главную ветку, также это позволит проверить код перед слиянием из краткосрочной feature-ветки обратно в главную ветку.
-
Число участников команды при необходимости может расти или сокращаться, без ущерба для пропускной способности или качества. Так, например, Google применяет в разработке подход Trunk-Based Development, при этом 25000 разработчиков и тестировщиков QA одновременно работают в одной главной ветке монорепозитория, который может разрастаться или сокращаться в соответствии с нуждами разработчика.
-
Командам, которые используют в разработке модель ветвления GitHub-flow, этот подход покажется близким, но есть одно небольшое различие в отношении того, откуда создается релиз.
-
Командам, которые используют в разработке модель ветвления Gitflow, этот подход покажется совершенно другим, как и для многих разработчиков, привыкших к популярным в прошлом моделям ветвления – ClearCase, Subversion, Perforce, StarTeam, VCS.
-
Ряд публикаций продвигает подход разработки на основе главной ветки, как мы в этой статье. К ним относятся бестселлеры «Непрерывная поставка» и «Руководство по DevOps». И здесь нет противоречий!
Заключение
Trunk-Based Development не является новым подходом. Он был тактически продуман еще в восьмидесятых годах, а с середины девяностых стал набирать популярность. Крупнейшие разработчики программных продуктов, такие как Google (как уже упоминалось) и Facebook, широко применяют данный подход в организции разработки.
За более чем 30 лет различные достижения в технологиях управления исходным кодом и связанных с ними инструментах сделали данный подход более (а иногда и менее) распространенным, но это модель является моделью ветвления, которой многие разработчики придерживаются на протяжении долгих лет. Она позволяет обойти проблемы, возникающие при работе в изолированных ветках, и придерживаться основных принципов CI/CD.
Если вам понравилась статья, поделитесь ей с друзьями.