trunk based development что это
Введение
Краткое описание
Модель ветвления в системен контроля версий, в которой разработчики работают над кодом в единственной ветке под названием ‘trunk’ *. Эта модель позволяет не создавать другие долгоживущие ветки и описывает технику как именно это делать. Разработчики избегают merge конфликтов при слиянии кода, не ломают сборку, и живут долго и счастливо.
* master, в терминологии Git
Общие ветки вне mainline/master/trunk это плохо при любом релизном цикле:
Trunk-Based Development для небольших команд:
Масштабированный Trunk-Based Development:
Разработка, Требования и Предостережения
Для того, чтобы определить границу между маленькой и большой Trunk-Based Development командами, нужно рассмотреть размер команды и скорость коммитов. Определение точного момента, когда команда разработки перестала быть маленькой и начала быть большой, лучше оставить тем, кто любит практиковаться в дебатах. Несмотря на это, любой член команды все равно делает полную “прединтеграционную” сборку (компиляция, прогон unit и интеграционных тестов) на своей рабочей станции прежде чем сделать commit/push кода в общую ветку.
Требования
Предостережения
В зависимости от размера комманды и частоты коммитов, feature ветки с коротким временем жизни используются для code-review и проверки сборки (CI), но не для создания артефактов или выпуска. Все проверки должны проходить до того, как произойдет слияние кода в ветку trunk, т.к. от этой ветки зависят другие разработчики. Такие ветки позволяют разработчикам быть вовлеченными в более быстрое и непрерывное code review коллег и/или других разработчиков до того, как их код будет влит в общую ветку trunk. Очень маленькие команды могут вливать код напрямую в trunk.
В зависимости от предполагаемой частоты релизов, у вас могут быть релизные ветки,которые создаются из ветки trunk в нужный момент. Ветки “застывают” до релиза (чтобы не было командной активности), и эти ветки удаляются через какое-то время после релиза. При другом подходе, релизных веток может не быть если команда разработки собирает релизы из trunk ветки и выбирает стратегию “правки по мере появления” для правки багов. Также, для того чтобы делать релизы из ветки trunk, команда должна обладать высокой пропускной способностью.
Если у вас на проекте работает больше двух разработчиокв, вам потребуется поднять сервер для сборки и настроить проверку того, что код этих разработчиков не ломает сборку после того, как он был влит в trunk, а также до того, как он будет влит в trunk из feature ветки с коротким временем жизни.
Команды разработки могут без проблем увеличивать или уменьшать число разработчиков (в trunk) без какого-либо негативного влияния на пропускную способность или качество. Доказательство? Их есть у меня. Google работает по Trunk-Based Development и у них есть 35000 разработчиков and QA автоматизаторов в этом единственном trunk монорепозитории, так что в их случае они могут добавлять или убирать разработчиков из монорепозитория по запросу.
Многие публикации рекомендуют Trunk-Based Development, которую мы тут описываем. Эти публикации включают в себя, например, ‘Continuous Delivery’ и ‘DevOps Handbook’. Так что дальнейших споров про это быть не должно!
История
Trunk-Based Development это не новая модель ветвления. Слово ‘trunk’(ствол) является отсылкой к концепции растущего дерева, где самая толстая и длинная ветка это trunk(ствол), а остальные ветки отходят от неё и имеют более короткую длину.
В середине 90-х, когда в проектах выбирали модель ветвления, про эту модель знали мало и редко выбирали ее, а в 80-х она вообще рассматривалась только в теоретическом ключе. В круплейших организациях по разработке ПО, таких как Google и Facebook, эту модель ветвления практикуют на больших командах.
Более чем 30 лет различных улучшений в технологиях контроля версий, а также сопутствующих инструментов и техник, сделали Trunk-Based Development более (а иногда и менее) преобладающей в разработке, но это та самая модель ветвления, которой придерживались многие компании на протяжении многих лет.
Об этом сайте
Этот сайт это попытка собрать все факты, объяснения и техники для Trunk-Based Development, в одном месте, а также дополнить это 25 диаграммами для более глубокого понимания.
Что такое Trunk Based Development (TBD)?
Перевод статьи «What is Trunk Based Development? A Different Approach to the Software Development Lifecycle».
Жизненный цикл разработки ПО (англ. Software Development Lifecycle, SDLC) в каждой компании свой.
Используемая система контроля версий, процедура код-ревью, осуществление непрерывной интеграции, автоматизированное и ручное тестирование и т. п. вещи будут очень сильно зависеть от того, где вы работаете.
То, как компания планирует, пишет, собирает, проверяет, деплоит и выпускает программы, подогнано под ее собственные нужды с учетом всех достоинств и недостатков выбранных подходов.
Я начал читать о том, какие есть жизненные циклы разработки ПО в разных технологических компаниях, и несколько раз наткнулся на термин Trunk Based Development. Это процедура, которой придерживается Google, и мне стало любопытно, чем она отличается от процедур, принятых в большинстве других компаний, занимающихся разработкой.
Два разных подхода к ветвлению
Ответвления для отдельных функций
Когда несколько разработчиков вместе работают над одной кодовой базой, они могут делать это двумя способами.
Первый подразумевает создание отдельных веток для всех создаваемых фич.
Чаще всего разработчики работают с системой контроля версий Git. Каждый из них делает форк кодовой базы на свою машину (в результате у всех есть идентичные копии всего кода). Затем все делают ответвления от основной ветки master и создают ветки фич или проектов, над которыми будут работать. Закончив работу над своей фичей, каждый разработчик сливает свои изменения обратно в master. Тут надо подчеркнуть, что merge делается только один раз, когда работа над фичей окончена, и в master мержится вся ветка этой фичи.
Вот схема того, как происходит работа с ветками:
Белые точки представляют коммиты, а непрерывная черная линия внизу это master. Разработчики делают ответвления от master, вносят изменения в свои ветки, а когда все готово и код прошел проверку, каждая отдельная ветка сливается обратно в master.
Trunk Based Development (TBD)
Второй подход к совместной работе над кодовой базой — TBD. При этом подходе все разработчики делят свою работу на маленькие порции и мержат свои изменения прямо в master по нескольку раз в день. Ветку master при этом часто называют trunk — англ. «ствол», по аналогии с деревом.
Разработчики не создают отдельных веток для своих фич и, естественно, не мержат их затем в «ствол». Вместо этого они делают коммиты напрямую в «ствол», обходясь вообще без веток.
TBD подразумевает, что изменения каждого отдельного разработчика не задерживаются вне главной ветки дольше, чем на несколько часов. Они постоянно мержатся и интегрируются с кодом, написанным другими разработчиками.
Джез Хамбл, Site Reliability Engineer в Google и автор книги «Continuous Delivery», сказал: «ветвление — не проблема, проблема — слияние». Именно эту проблему и призван решить подход TBD.
Цель TBD — избежать болезненного мержа, а он часто бывает болезненным, если в trunk мержатся долгоживущие ветки, которые уже слишком сильно отличаются от ствола. И если разные разработчики (или даже разные команды) сливают несколько веток в одну, прежде чем слить ее в trunk, — merge тоже редко бывает беспроблемным.
Насколько подход TBD применим в больших проектах?
Рейчел Потвин, Engineering Manager в Google, рассказала об одной кодовой базе. В январе 2015 года в этой базе было:
При работе над этой кодовой базой они применяли TBD, и для их нужд этот подход отлично работал. Поскольку в Google работает много талантливых (и, что более важно, — опытных) инженеров, они редко ломают свои сборки.
Также в Google существует очень строгая процедура тестирования (почитать о ней можно здесь). При применении TBD эта процедура тестирования делает возможной быструю и эффективную поставку ПО.
TBD также хорошо сочетается с Agile-методологиями, предполагающими частые поставки для быстрого получения фидбэка от пользователей или клиентов. С TBD вы можете непрерывно интегрировать изменения и получать хорошие снимки текущего состояния кодовой базы.
Давайте коротко обсудим преимущества TBD.
Преимущества TBD
Недостатки TBD
Как релизить программы, применяя TBD
У команды, которая придерживается TBD, процедура релиза будет отличаться от аналогичной процедуры в команде, где используются ветки фич.
Допустим, вы работаете с ветвлением. Когда вы мержите что-то (тикеты, завершенные проекты и т. п.) в master, вы делаете релиз этой основной ветки. В некоторых командах релиз master происходит по расписанию, скажем, раз в неделю.
А вот как обстоят дела с релизами в TBD-командах:
В TBD ответвления используются исключительно для релизов.
Вы делаете «снимок» вашей кодовой базы в ее стабильном состоянии, готовом к деплойменту и релизу.
В приведенной выше схеме могут появиться дополнительные детали, только если с релизом prj-123 что-то пойдет не так. Тогда мы коммитим результат в trunk и выбираем (cherry pick) коммиты в нашу ветку релиза, чтобы как можно быстрее привести ее в рабочее состояние.
В некоторых командах, если релизы у них происходят регулярно, вообще обходятся без ответвлений и, когда необходимо, делают релиз trunk.
Заключение
Теории и практике TBD посвящен отдельный сайт, там вы можете узнать гораздо больше.
Надеюсь, прочитав эту статью, вы поняли, что такое Trunk Based Development и зачем нужен этот подход. Он определенно помогает избавиться от многих проблем, связанных со слиянием долгоживущих веток.
Мнение: пушить сразу в мастер — хорошо. Обсуждаем Trunk Based Development
Авторизуйтесь
Мнение: пушить сразу в мастер — хорошо. Обсуждаем Trunk Based Development
Мэттия Бэттистон опубликовал на площадке Medium статью, где рассказал, почему ему нравится пушить сразу в мастер и какие выгоды для команды он видит в таком подходе. Публикуем его рассказ и два противоположных мнения о Trunk Based Development.
Прим. ред. Мнение редакции может не совпадать с мнением автора оригинала.
Разработка с помощью пулл-реквестов и feature-веток (даже краткосрочных) проще для индивидуальной разработки, но в целом не является оптимальной стратегией для команды.
Обычно командам, использующим краткосрочные ветки, было бы лучше работать прямо в мастере, так как практики, которые им нужно соблюдать, чтобы безопасно следовать trunk based development, приносят множество преимуществ: улучшение командной работы, улучшение качества работы, коллективное владение кодом и не только.
«Нет, мы не пушим в мастер, ты совсем что ли?»
Позвольте рассказать вам историю.
Недавно я устроился в консалтинговую компанию. Самая интересная часть работы консультантом заключается в том, что вам приходится работать с множеством клиентов. Так, с начала работы несколько месяцев назад я поработал с тремя разными командами. Они состояли примерно из 6–8 человек, работающих в одном офисе. В основном это были программисты плюс product owner, иногда ещё и scrum master. Почти все в команде сидят рядом друг с другом, не считая странного человека, который изо дня в день работает из дома.
Когда я присоединяюсь к команде, я всегда задаю много вопросов, в основном чтобы понять, как она работает и как я могу помочь. С каждой из трёх команд неизбежно заходил разговор о контроле версий, который проходил примерно так:
Я: «Так, что происходит, когда я делаю коммит?».
Они: «Тебе нужно создать пулл-реквест, скинуть ссылку в Slack и подождать, пока кто-нибудь его проверит».
Я: «А, то есть вы не пушите сразу в мастер?».
Они: *уставились на меня широко открытыми глазами, словно увидели пришельца… несколько секунд тишины…*
Они *неодобрительно качая головами*: «Нет, мы не пушим в мастер. Код сначала нужно проверить».
И тут я прямо вижу, как они думают: «Он серьёзно? И вот этот человек должен нам «помочь»?».
Само собой, я не против, когда люди ставят под сомнение мои идеи и противятся им, это часть моей работы. Но что меня удивило, так это сколько сопротивления встретила идея, что кто-то мог даже подумать о пуше в мастер. Я много гуглил и поспрашивал людей из других компаний, и оказалось, что feature-ветки — нормальное явление. Тут даже и говорить не о чем, так работает IT-индустрия.
Будучи выходцем из компании, где пушить в мастер было нормой, я подумал и решил написать эту статью. Я хочу объяснить, почему я уверен, что обычно командам, которые используют краткосрочные feature-ветки, будет выгодней делать всё в мастере, а не в этих ветках.
Как команды используют краткосрочные feature-ветки и пулл-реквесты
Давайте объясню, как из моих наблюдений выглядит типичный рабочий процесс команды, использующей краткосрочные feature-ветки:
Ваш рабочий процесс может отличаться, но я думаю, что всё это звучит знакомо многим людям. Этот процесс известен под именем GitHub Flow.
Просто для ясности, я знаю, что команды могут использовать ветки и другими способами, например, Gitflow с долгоживущими ветками. Эти стратегии ветвления открывают целый новый мир проблем. Если вы хотите услышать об этих проблемах, я рекомендую эту презентацию Стива Смита. Однако в этой статье я хочу сосредоточиться на проблемах краткосрочных feature-веток и почему я думаю, что командам будет лучше работать, придерживаясь TBD.
Успешная альтернатива: Trunk Based Development, без веток
Что я предлагаю в качестве альтернативы, так это работать напрямую в мастере, без использования веток. Само собой, нужно делать это безопасным образом. Чтобы это стало возможным, команда должна использовать следующие основные методы:
1. Парное программирование
Вам нужно заниматься парным программированием и делать это часто. При работе в паре с другим человеком код пишется и проверяется в реальном времени, что исключает дальнейшую необходимость в PR. Более того, парное программирование приносит невероятное количество пользы команде:
Порой это можно даже перенести на следующий уровень и устроить совместный сеанс программирования, когда вся команда работает над одной вещью на одном компьютере (например когда нужно принять командное решение вроде выбора архитектуры).
2. Имейте сборку, которой доверяете
Вам нужна сборка, которой вы доверяете. Она должна запускать достаточно автоматизированных тестов, чтобы вы были уверены, что кодовая база находится в состоянии, удовлетворительном для релиза. Также она должна быть достаточно быстрой, чтобы вы могли запустить её локально перед пушем в мастер, так как вы не хотите запушить что-то сломанное, что помешает остальной части команды.
Для достижения этих двух вещей команды обычно следуют практикам вроде TDD, BDD и имеют эффективную стратегию тестирования, например следуют пирамиде тестирования, чтобы свести к минимуму количество медленных тестов.
Если сборка вдруг ломается, её починка немедленно становится приоритетом команды. В маловероятном случае, если не удалось сделать это быстро, нужно сделать откат изменений.
3. Используйте «ветвление через абстракцию» или feature-флаги, чтобы спрятать незаконченный код
В любой момент времени в мастере будет незаконченный код. Это не приносит никакого вреда, так как такой код ещё не используется в продакшне. Зато от его нахождения в мастере есть польза: вы быстрее замечаете проблемы интеграции, вы можете провести более сложный рефакторинг и вы можете доказать, что код будет работать, написав для него тесты.
На деле я обнаружил, что в большинстве случаев можно использовать шаблон «ветвление через абстракцию», чтобы избежать использования кода в продакшне до его готовности. Для более сложных сценариев я использовал feature-флаги.
В моей предыдущей компании работать так было нормой. Я проработал там около 6 лет, но я знаю, что там следовали этим практикам более 10 лет. Так что я точно знаю, что такой способ работы может быть успешным (в конце статьи буду подробности того, как мы работали).
Преимущества Trunk Based Development
Я считаю, что описанные мной практики приносят команде массу преимуществ и хорошее взаимодействие, к чему команды должны стремиться. Применив их, вы сможете забыть о ветках и начать безопасно пушить сразу в мастер. Вот некоторые из преимуществ, которые я заметил:
Trunk Based Development — показатель здоровья команды
Позвольте быть предельно ясным: TBD сам по себе не является чем-то особенным и не даёт каких-то особых преимуществ. Что их даёт, так это практики, которым нужно следовать для применения TBD. Чтобы команда могла работать прямо в мастере, её члены должны знать, как работать, не ломая код, как писать хорошие тесты, как работать вместе эффективно и так далее.
Можно сказать, что TBD является показателем здоровья команды. И этому действительно есть подтверждение в книге «Accelerate»: после изучения более 10 000 сотрудников и 2 000 организаций исследование показало, что существует тесная взаимосвязь между командой, следующей TBD, и высокими показателями эффективности этой команды. В частности, было обнаружено, что в высокоэффективных командах срок жизни веток составляет менее суток.
Оптимизация эффективности команды
Когда я спрашиваю у команд, почему они используют ветки или почему они думают, что не стоит пушить сразу в мастер, мне обычно отвечают что-то вроде: «Мы должны поддерживать мастер в хорошем состоянии, готовом к релизу» или «Мы хотим проверять код друг друга, чтобы убедиться, что он хорошего качества и соответствует нашим стандартам». Я полностью согласен с обоими утверждениями, но в этой статье я показал вам, как добиться тех же результатов без использования веток.
Однако есть и другая причина, о которой часто умалчивают, почему так много команд используют feature-ветки: «Гораздо проще и эффективнее, когда все работают со своими ветками и не наступают друг другу на пятки».
И хотя это утверждение справедливо, я с ним категорически не согласен. Именно отсюда растут многие проблемы команд. Большинство команд оптимизируют работу отдельного человека, а не всей команды. Они смотрят на продуктивность отдельного человека, а не команды. В терминологии Lean, это является прекрасным примером оптимизации ресурсоэффективности вместо эффективности рабочего процесса.
Feature-ветки оптимизируют индивидуальную производительность, но TBD оптимизирует производительность команды. Когда вы проводите оптимизацию команды, начинает казаться, словно каждый её член начинает работать медленнее. Это смена подхода, которая выглядит нелогично. Но именно так группа отдельных разработчиков превращается в команду.
Хорошие примеры использования feature-веток
После долгих разговоров о том, почему не следует использовать feature-ветки, думаю, стоит прояснить следующее: да, в определённых случаях от них есть польза. Как правило, я бы сказал, что feature-ветки хорошо использовать, когда у кода есть явный владелец, но кто-то другой делает всю работу.
Прекрасный тому пример — open-source модель: в типичном open-source проекте есть владелец, будь то один человек или команда, а ещё есть множество разработчиков со всего света, вносящих вклад в проект без общения друг с другом. В этом случае имеет смысл просить разработчиков отправлять PR, так как владельцам проекта нужно его проверить. Собственно, это то, для чего в GitHub придумали PR! Также в таком случае владельцам проще отклонить любой PR, с которым они не согласны.
Аналогичная ситуация иногда возникает в компаниях, использующих внутреннюю open-source модель: код принадлежит одной команде, но поскольку разработчики слишком заняты, чтобы работать над ним, другая команда вносит в него свой вклад, отправляя PR. Это не единственное решение этой проблемы, но иногда это хороший компромисс.
«Окей, убедили. Как мне начать использовать этот подход?»
Если сейчас вы работаете с feature-ветками и хотите перейти к работе с мастером напрямую, вот несколько предложений:
Ресурсы по теме
Вот хорошие ресурсы, если вы хотите больше узнать о TBD:
Бонус: реальный пример Trunk Based Development
Вот подробная информация о том, как моя предыдущая команда следовала TBD и пушила сразу в мастер. Команда была похожа на описанные выше: 6–10 человек, из них 4–6 разработчиков, 1–2 тестера, 1 бизнес-аналитик и 1 тимлид.
Мнения
Само собой, нельзя ожидать, что все посчитают TBD решением всех проблем. Мнения насчёт этой методологии разделились, и мы решили привести примеры как противников TBD, так и сторонников. Мнение противника:
И мнение сторонника:
А что вы думаете о TBD? Делитесь в комментариях.
Вам больше не нужны ветви для фич…
Mar 27, 2020 · 3 min read
Что такое магистральная разработка?
Магистральная разработка (Trunk Based Development — TBD) — процесс разработки ПО. Согласно trunkbaseddevelopment.com (отличный источник информации о TBD) он определяется как:
Модель ветвления, в которой разработчики совместно работают над кодом в одной ветви, называемой “стволом”. При этом другие ветви имеют короткий срок жизни благодаря использованию документированных методов.
Идея заключается в том, что вместо создания ветви функции для разработки кода, которая затем объединяется с основной ветвью, эта функция разделяется на небольшие части, каждая из которых по окончании работы над ней помещается в главную ветвь.
Другими словами… команда занимается разработкой без использования веток.
Помимо то г о, что небольшие изменения кода в формате TBD сокращают количество конфликтов слияний (повышая настроение разработчиков), магистральная разработка предоставляет преимущества и в других областях:
Частота развертывания и среднее время восстановления
TBD в сочетании с конвейером CI/CD приводит к тому, что каждый “зеленый” коммит (т.е. полная функциональность кода, проверенная с помощью тестов) развертывается на производстве. Перенос каждого изменения в главную ветку предполагает большую интеграцию и развертывание.
Способность быстро развертывать изменения с помощью TBD и CI/CD также позволяет команде с легкостью “выполнить откат” при обнаружении проблем.
Качество кода и обмен знаниями
Наибольший страх, с которым сталкиваются команды при рассмотрении TBD, заключается в том, что качество кода в базе пострадает, а вероятность ошибок возрастет. На самом деле, TBD приводит к гораздо более устойчивому и качественному коду.
Большинство команд, использующих ветви функций, применяют пул-реквест, с помощью которого другие разработчики могут просматривать и комментировать код.
Отсутствие ветвей функций в TBD также предполагает отсутствие пул-реквестов. Однако это не должно стать проблемой. Большинство команд нуждаются в “принципе 4-х глаз”, который гласит, что минимум 2 разработчика должны просмотреть и одобрить код перед отправкой в главную ветку.
Достичь выполнения этого принципа можно с помощью парного программирования. Два разработчика, решающие одну проблему, зачастую справляются лучше, чем те, кто работает в одиночку. Все члены команды обладают разным уровнем опыта и знаний технологического стека и/или системы, которую разрабатывает команда. Совместная работа предоставляет возможность учиться у товарищей по команде в ускоренном темпе.
Командная работа
Парное программирование также является формой командной работы, однако TBD повышает уровень эмпатии всех ее участников.
Если старший разработчик захочет увидеть код, написанный младшим, они могут объединиться, и быстрее, чем они успеют это осознать, младший уже будет писать код, достойный гордости старшего.
Потенциальные трудности
Незаконченные функции
Никто не будет предлагать недоработанные функции, такие как кнопка без функциональности, клиентам на производстве. Чтобы избежать этого, команды могут реализовать переключатели функций, за которыми скрываются незавершенные функции. Если работа над функцией не завершена, флаг функции отключается, а когда последний фрагмент выполнен и готов к выпуску, флаг можно включить (или полностью удалить). При использовании переключателей функций можно также применять A/B-тестирование или “канареечный” релиз.
Тестирование и мониторинг
Магистральная разработка требует наличия сильного набора тестов и качественного мониторинга, чтобы как можно быстрее выявлять ошибки. Чем быстрее цикл обратной связи, тем лучше. Починка сломанного конвейера — приоритет номер один для членов команды, ответственных за его поломку.
Этого можно избежать с помощью внедрения небольших изменений, использования среды разработки, максимально схожей с тестовыми и производственными средами, а также выполнения локальных задач конвейера перед отправкой (например, с помощью git-хуков).
Множество команд уже реализовали магистральную разработку, и ни одна из них не вернулась к более распространенной модели пул-реквестов. Однако не стоит забывать о том, что в ПО, как и в жизни, один подход работает не для всех. Необходимо выбрать именно тот, который наилучшим образом подходит для вашей команды.