trunk git что это
Что такое 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 и зачем нужен этот подход. Он определенно помогает избавиться от многих проблем, связанных со слиянием долгоживущих веток.
Branching стратегии в Git
Прежде чем поговорить о лучших практиках, давайте разберемся с худшими практиками и анти-паттернами при работе с любой бранч стратегией.
Branching & merging анти-паттерны:
Git Flow (Feature Based Development)
Схематично Git Flow можно описать так:
Git Flow — одна из первых крупных стратегий ветвления, которая завоевала популярность. Git Flow описывает несколько веток для разработки, релизов и взаимодействия между ними.
Главные ветки:
По сути модель перекочевала с других существующих моделей. Репозиторий содержит 2 главные ветки:
Feature branches
Release branches
Помните, до того как вмержить код в релиз ветку, необходимо добавить ей тег с версией релиза (например «0.9 hotfix»)
Hotfix branches
Плюсы и минусы Git Flow:
Плюсы:
Минусы:
GitHub Flow
Он выглядит почти так же как и Git Flow, но фиксированная ветка всего одна — master ; всё остальное принадлежит тематическим ветвям. Тематические ветви, в свою очередь, создаются в форках — клонированных копиях репозитория. То есть центральный репозиторий тематических веток не содержит. В том числе и после слияния, так как метки веток при этом снимаются и их головы становятся анонимными.
GitLab Flow
Как и в GitHub Flow, фиксированная ветка всего одна — master, всё остальное принадлежит тематическим ветвям. Однако, если в том случае релизы размещались в коммитах master-a, то здесь для каждого релиза создаётся своя, отдельная ветка. Причём никакого мержа этих веток с parent’ом не производится. Если ветка отбранчевалась, значит она будет жить своей жизнью, получая исправления ошибок в виде отдельных коммитов (возможно, портированных из head/master с учётом накопившейся разницы в функционале между ветками).
Environment branches в GitLab flow
Release branches в GitLab flow
Trunk Based Development (TBD)
На официальном сайте эта концепция отображается такой схемой:
Лично для меня, когда я стал изучать эту концепцию эта схема показалась совсем не понятной и не раскрывала суть этой концепции. Давайте же разберемся подробнее простым языком в чем суть Trunk Based Development.
TBD прозволяет бизнесу тестировать бизнес-гипотезы «As soon as possible». Тк позволяет очень быстрыми итерациями релизить код на продакшн.
В Trunk Based Development можно выделить следующие особенности:
Feature Flags
Feature Flags — это концепция в которой у нас есть файл конфигурации, где прописано какая из фич включена/выключена и в коде существует проверка которая позволяет пропускать какую-то логику, например
Приемущества использования Feature Flags
Branch By Abstraction
Trunk Based Development предлагает вместо создание ветки для фич, создавать ветку на изменение одной абстракции.
Рассмотрим рисунок и шаги которые нам помогут раскрыть порядок действий при TBD подходе
И что нам это дало?
Continuous Code Review
Ревьювим чужие pull requests, сразу после того как отправили свой. Из-за этого что пулл реквесты маленькие(изменение одной абстракции), их ревью занимает не более чем пару минут, Если от создания пулл реквеста до аппрува прошло 10 минут, то это приемлемый результат, если больше 1 часа, то это считается очень плохим результатом.
Что нам дает концепт Continuous Code Review
Плюсы и минусы Trunk Based Development
Плюсы:
Минусы:
Почему Trunk Based Development – лучшая модель ветвления. Андрей Александров
В State Of DevOps 2018 от DORA мы видим, что Нigh Performing компании используют Trunk Based Development. Разберемся, почему именно ее, какие ее преимущества и недостатки имеет эта модель.
Всем привет! Меня зовут Андрей. Я DevOps-консультант. Работаю в Express 42, по совместительству ведущий подкаста DevOps Deflope. И сегодня я рассказу про Trunk Based Development.
Это штука очень сложная. Я не уверен, что у меня получится за 10 минут объяснить все концепции, идеи, которые за ней стоят.
Почему эта модель лучше? Я не буду рассуждать на тему: лучше она или нет, потому что пруфы в индустрии уже есть:
Я буду сосредотачиваться только на том, почему и зачем это нужно.
Мы хотим тестировать бизнес-гипотезы как можно быстрее. Мы хотим выдвинуть идею, протестировать, отдать пользователям. И Trunk Based Development идеально для этого подходит.
В чем суть Trunk Based Development?
Поговорим про все эти штуки. Почему они хороши?
Все начинается с Feature Flags. Все следующие шаги без этой штуки сделать не получится.
В чем идея Feature Flags? В том, что мы теперь с помощью ключика можем сказать, какие фичи мы включаем, а какие нет. Большая часть фич оборачивается в Feature Flags. И когда мы запускаем наше приложение, мы говорим, что теперь наши пользователи могут за один клик покупать. И таким образом мы можем делать A/B тесты и мержить в мастер те фичи, которые еще не готовы.
Что дает нам включение-выключение фич?
Когда я раньше писал код за деньги, у меня была большая боль. В чем была проблема? У меня есть большой pull request. Я в нем сделал кучу абстракций, полей в базе данных и прочее. И они уже нужны в других фичах. Но мы не можем это переиспользовать, потому что у меня еще не все готово. И мы не можем это смержить. А Trunk позволяет все это делать, потому что у нас Feature Flags как обязательный подход.
Вот это самая сложная вещь. Тут очень многие люди совершают ошибку. У нас больше нет веток для фич. Это сложная концепция.
В чем идея? Мы больше не делаем ветки для фич, мы делаем ветки на изменение одной абстракции.
Например, у нас есть машинка, в ней есть абстракция «передние колеса» и «задние колеса». И мы хотим, чтобы эти колеса работали как-то по-другому. Например, чтобы был другой тип колес, шин.
Как в случае с Trunk будем их менять?
Мы задачу по замене колес, которая большая и сложная с кучей рефакторинга, декомпозировали на маленькие кусочки. И pull requests делаем на изменение одной маленькой абстракции. Вот это ключевая идея. И это то, за счет чего Trunk получается очень быстрым.
Что дает нам такой подход?
Соответственно, мы теперь работаем маленькими кусочками, меняем одну абстракцию за раз и это нам позволяет использовать подход Continuous Review.
Это все очень-очень сложно. Я пытался уже несколько раз рассказывать про Trunk. И каждый раз у людей складывалось впечатление, что это как Git Flow или GitHub Flow, но только проще, потому что нет пару лишних веток, поэтому Trunk Based Development очень простой. Нет, эта штука очень сложная.
И, поверьте, это не так просто. По моему опыту общения с программистами далеко не у всех все хорошо с применением SOLID‑практик. Если ваши программисты разбираются в SOLID, то, скорее всего, эта абстракция у них есть и так. Потому что SOLID нам говорит: «Делай объект, а вокруг него делай еще интерфейс-абстракцию». Если у программиста с этим проблемы, то не взлетит, надо будет все это подтягивать.
Почему, несмотря на все эти сложности, мы приходим к тому, что она лучшая?
Тут парочка полезных ссылочек:
Приветствую! Допустим, у нас есть команда, у которой нет вообще никаких процессов, т. е. даже Git Flow нет. Теоретически мы можем пропустить итерацию выстраивания Git Flow и прочих процессов, а сразу прыгнуть в Trunk Based? И насколько это реально?
Теоретически можно. Trunk Based Development очень сильно вариативный. Если сейчас не получается прыгнуть сразу в Branch By Abstraction, то можно сделать Short-Lived Branches. Это как фичи-ветки, только они живут очень мало. Один-два дня – максимальное время жизни ветки от создания. Можно зайти с этого. Можно сделать короткоживущие ветки, а потом сверху все остальное. Можно попробовать так.
Ты сказал, что для принятия pull request его должно посмотреть достаточное количество глаз. Обычно при разработке у нас есть TeamLead, который просматривает все поступающее и принимает единоличное решение о включении или не включении в текущий Branch. Каким образом вы организовываете pull request, что у вас несколько человек смотрят и принимают решение? У вас голосование?
Можно делать по-разному. Можно, чтобы просто любой коллега посмотрел. Делать так, что все pull requests смотрит TeamLead – это плохая идея, потому что их теперь у тебя очень много, они очень частые и он становится бутылочным горлышком.
Т. е. не несколько человек смотрят все-таки?
Это как принято в компании. Может смотреть несколько, может один человек. Но хоть кто-то должен посмотреть, иначе у тебя не будет никаких плюшек от review, т. е. нет шаринга, нет моментального рефакторинга и т. д.
Привет! Спасибо большое за доклад! Какого размера примерно проект должен быть? Это должен быть маленький проект, микросервисы или это идеология натягивается на любой размер проекта?
Абсолютно на любой. У тебя по большому счету претензия к архитектуре в этом случае. Если ты монолит сделал по условному SOLID, у тебя все абстракции нормально разделены, то у тебя никаких проблем не будет. Ты за счет этого подхода, даже если изначально он был сделан плохо, можешь его кусочками-кусочками медленно рефакторить. И при этом своим рефакторингом абсолютно не блокируешь коллег.
Накрывается ли тестами работа Feature Flags? И насколько большой overhead для разработки, для тестирования вот это покрытие вызывает?
Мы должны тестировать и вариант, когда фича включена и вариант, когда она выключена, иначе мы не понимаем ломаем ли мы prod или нет.
А насколько overhead? Тут не очень понятно, как мерить.
Т. е. два раза нужно написать тест? Нужно написать для старой фичи, нужно написать для новой фичи?
Нет, тест для старой фичи у тебя не пишется, потому что ты его уже писал.
Он уже есть, да. А для новой нужно написать. И внутри написать включилось и не включилось.
Да, ты внутри теста старой абстракции пишешь «if включена новая фича», тогда вот эти тесты новые. Also – старые. И прогоняешь и то, и то. Я не вижу тут какого-то overhead, кроме добавления строчки if, потому что старые тесты у тебя есть, новые ты добавляешь.
Спасибо за доклад! У нас большой проект. У нас Trunk Based Development уже год.
Все отлично, все работает. Только у нас SVN. И поэтому мы просто коммитим прямо в Trunk. И у нас нет pull request, мы коммитим прямо в Trunk. Все здорово и хорошо. Спасибо автотестам. Но пришли новые люди и начали ныть: «Давайте нам Git Flow, ваш Trunk Based – это какой-то ужас». И мы прогнулись, и решили переехать на Git. И сейчас у нас пол проекта в SVN, полпроекта в Git. Скоро весь проект будет в Git. И мне страшно. Мне Trunk Based Development нравится. И мне страшно от него отказываться. Если переехать с такого вида, когда мы коммитим прямо в Trunk, на такое, мы не замедлимся? Т. е. если Short-Lived Branches не по фичам, а Branch By Abstraction, то это не замедлит нас?
У тебя один коммит в мастер – это целая фича?
Нет, у меня один коммит в мастер – это просто кто-то что-то написал и коммитит.
Я понял. Branch By Abstraction, только Commit By Abstraction фактически?
Если вы все-таки начинаете друг друга ревьювить, то это плюс две минуты на ревью кого-то.
Мы в Trunk смотрим и если что-то там плохо, то правим.
Тогда не должно быть никаких проблем. Если мы посмотрим тот же trunkbaseddevelopment.com, то он говорит, что если вы очень крутые, то можете прямо в мастер фигачить. Но вы должны быть очень крутыми, чтобы так делать. видимо, вы крутые.
Привет! Спасибо за доклад! Я хотел по этой картинке спросить (Branch By Abstraction вместо feature branch). Ты говоришь, что над любой фичей должна быть абстракция. Почему тогда не остановится на 4-ом варианте? Если в следующий раз нужно будет что-то поменять, то нужно будет эту абстракцию дополнительно пилить как в первом шаге.
Есть два варианта. Есть вариант, когда мы эту абстракцию оставляем и есть вариант, когда мы ее убираем. Все делают по-разному. Если мы посмотрим, например, на блог Fowler, то он говорит, что эту штуку давайте оставим, пусть у нас для всего будет abstraction layer или layer интерфейса. Это пример с Trunk Based Development, они объясняют эту штуку так. Но можно оставлять, можно убирать – это не принципиально. Но я бы рекомендовал все-таки оставить. Т. е. мы удалили старый вариант, но оставили новый тип колес и абстракцию, через которую мы все еще можем с этим что-то делать.
И еще вопрос у меня по Code Review. Очевидно, когда приходит junior-разработчик в команду, то его Code Review вряд ли будет занимать 10 минут и PR вряд ли будет висеть час. Это может быть и дольше, и может быть отклонено. Что будет в таких случаях? Или ты не берешь вообще juniors в команду?
Можно раскрыть вопрос?
Когда junior берется за дело, то ему требуется больше комментариев по коду и т. д. И, возможно, какие-то исправления необходимо вносить в pull request. А ты говоришь, что pull request висит 10 минут, т. е. он не успеет за 10 минут, скорее всего, поправить. Что делать?
У тебя junior будет исключением. 10 минут – это еще приемлемый результат. Если больше часа, то мы считаем это плохим результатом. Понятно, что Junior будет сложно. Скорее всего, он еще не те абстракции менял или не оттуда зашел. Для него придется сделать исключение.
Можно картинку с машинкой? Вот здесь все вроде бы понятно и хорошо. Мы меняем только колеса. А что если это будет не машинка, а здоровенный космолет из 50 150 частей, которые одновременно изменяются? Ладно, давайте вернемся к этой машинке. У нас несколько команд одновременно изменяет кто-то поведение фар, кто-то поведение стекла, колеса. В итоге выглядит более логичным, чтобы вместо красного корпуса была одна здоровенная абстракция, либо мы ее тоже будем менять. Не приводит ли это к тому, что у тебя начинается какая-то безумная простыня из Feature Flags, когда не понятно, как эти изменения должны друг с другом взаимодействовать? Потому что измененное стекло пусть даже с абстракцией не будет взаимодействовать через корпус с новыми колесами и ее абстракциями. Я уже сам запутался, пока объяснял.
Я понял. Основной вопрос в том, что будет, если мы параллельно меняем кучу всего.
Да, когда проект большой и изменений много в один момент времени.
Проблем не будет и вот почему. У тебя тут абстракция интерфейсная, которая позволяет колеса менять. Тут абстракция, позволяющая фары менять. Тут абстракция, позволяющая менять стекла. Почему это не будет сложно? Потому что у тебя в каждый момент времени все разработчики знают, что меняется. У тебя разработчик шлет сюда pull request на изменение фары, но он работает с максимально актуальным кодом, потому что мы мержимся каждые несколько минут. Поэтому он видит, что еще делают его коллеги. И, возможно, они объединятся и сделают какой-то единый вариант абстракции или еще что-то. У тебя, когда кто-то будет слать сюда pull request, он будет видеть, что другие коллеги уже тоже что-то делают.
Я вспомнил, что хотел сделать опрос. Поднимите руку, кто до этого момента слышал про Trunk. Неплохо, почти треть. А кто использует его у себя в проектах? 4 человека.
Trunk-based development
Learn why this version control management practice is common practice among DevOps teams.
Summary: Trunk-based development is a version control management practice where developers merge small, frequent updates to a core “trunk” or main branch. Since it streamlines merging and integration phases, it helps achieve CI/CD and increases software delivery and organizational performance.
In the early days of software development, programmers didn’t have the luxury of modern version control systems. Rather, they developed two versions of their software concurrently as a means of tracking changes and reversing them if necessary. Over time, this process proved to be labor-intensive, costly, and inefficient.
Gitflow, which was popularized first, is a stricter development model where only certain individuals can approve changes to the main code. This maintains code quality and minimizes the number of bugs. Trunk-based development is a more open model since all developers have access to the main code. This enables teams to iterate quickly and implement CI/CD.
What is trunk-based development?
Trunk-based development is a version control management practice where developers merge small, frequent updates to a core “trunk” or main branch. It’s a common practice among DevOps teams and part of the DevOps lifecycle since it streamlines merging and integration phases. In fact, trunk-based development is a required practice of CI/CD. Developers can create short-lived branches with a few small commits compared to other long-lived feature branching strategies. As codebase complexity and team size grow, trunk-based development helps keep production releases flowing.
Gitflow vs. trunk-based development
Gitflow is an alternative Git branching model that uses long-lived feature branches and multiple primary branches. Gitflow has more, longer-lived branches and larger commits than trunk-based development. Under this model, developers create a feature branch and delay merging it to the main trunk branch until the feature is complete. These long-lived feature branches require more collaboration to merge as they have a higher risk of deviating from the trunk branch and introducing conflicting updates.
Gitflow also has separate primary branch lines for development, hotfixes, features, and releases. There are different strategies for merging commits between these branches. Since there are more branches to juggle and manage, there is often more complexity that requires additional planning sessions and review from the team.
Trunk-based development is far more simplified since it focuses on the main branch as the source of fixes and releases. In trunk-based development the main branch is assumed to always be stable, without issues, and ready to deploy.
Benefits of trunk-based development
Trunk-based development is a required practice for continuous integration. If build and test processes are automated but developers work on isolated, lengthy feature branches that are infrequently integrated into a shared branch, continuous integration is not living up to its potential.
Trunk-based development eases the friction of code integration. When developers finish new work, they must merge the new code into the main branch. Yet they should not merge changes to the truck until they have verified that they can build successfully. During this phase, conflicts may arise if modifications have been made since the new work began. In particular, these conflicts are increasingly complex as development teams grow and the code base scales. This happens when developers create separate branches that deviate from the source branch and other developers are simultaneously merging overlapping code. Luckily, the trunk-based development model reduces these conflicts.
Allows continuous code integration
In the trunk-based development model, there is a repository with a steady stream of commits flowing into the main branch. Adding an automated test suite and code coverage monitoring for this stream of commits enables continuous integration. When new code is merged into the trunk, automated integration and code coverage tests run to validate the code quality.
Ensures continuous code review
The rapid, small commits of trunk-based development make code review a more efficient process. With small branches, developers can quickly see and review small changes. This is far easier compared to a long-lived feature branch where a reviewer reads pages of code or manually inspects a large surface area of code changes.
Enables consecutive production code releases
Teams should make frequent, daily merges to the main branch. Trunk-based development strives to keep the trunk branch “green”, meaning it’s ready to deploy at any commit. Automated tests, code converge, and code reviews provides a trunk-based development project with the assurances it’s ready to deploy to production at any time. This gives team agility to frequently deploy to production and set further goals of daily production releases.
Trunk-based development and CI/CD
As CI/CD grew in popularity, branching models were refined and optimized, leading to the rise of trunk-based development. Now, trunk-based development is a requirement of continuous integration. With continuous integration, developers perform trunk-based development in conjunction with automated tests that run after each committee to a trunk. This ensures the project works at all times.
Trunk-based development best practices
Trunk-based development ensures teams release code quickly and consistently. The following is a list of exercises and practices that will help refine your team’s cadence and develop an optimized release schedule.
Develop in small batches
Small changes of a couple of commits or modification of a few lines of code minimize cognitive overhead. It’s much easier for teams to have meaningful conversations and make quick decisions when reviewing a limited area of code versus a sprawling set of changes.
Feature flags
Feature flags nicely compliment trunk-based development by enabling developers to wrap new changes in an inactive code path and activate it at a later time. This allows developers to forgo creating a separate repository feature branch and instead commit new feature code directly to the main branch within a feature flag path.
Feature flags directly encourage small batch updates. Instead of creating a feature branch and waiting to build out the complete specification, developers can instead create a trunk commit that introduces the feature flag and pushes new trunk commits that build out the feature specification within the flag.
Implement comprehensive automated testing
Automated testing is necessary for any modern software project intending to achieve CI/CD. There are multiple types of automated tests that run at different stages of the release pipeline. Short running unit and integration tests are executed during development and upon code merge. Longer running, full stack, end-to-end tests are run in later pipeline phases against a full staging or production environment.
Automated tests help trunk-based development by maintaining a small batch rhythm as developers merge new commits. The automated test suite reviews the code for any issues and automatically approves or denies it. This helps developers rapidly create commits and run them through automated tests to see if they introduce any new issues.
Perform asynchronous code reviews
In trunk-based development, code review should be performed immediately and not put into an asynchronous system for later review. Automated tests provide a layer of preemptive code review. When developers are ready to review a team member’s pull request, they can first check that the automated tests passed and the code coverage has increased. This gives the reviewer immediate reassurance that the new code meets certain specifications. The reviewer can then focus on optimizations.
Have three or fewer active branches in the application’s code repository
Once a branch merges, it is best practice to delete it. A repository with a large amount of active branches has some unfortunate side effects. While it can be beneficial for teams to see what work is in progress by examining active branches, this benefit is lost if there are stale and inactive branches still around. Some developers use Git user interfaces that may become unwieldy to work with when loading a large number of remote branches.
Merge branches to the trunk at least once a day
High-performing, trunk-based development teams should close out and merge any open and merge-ready branches at least on a daily basis. This exercise helps keep rhythm and sets a cadence for release tracking. The team can then tag the main trunk at the end of day as a release commit, which has the helpful side effect of generating a daily agile release increment.
Reduced number of code freezes and integration phases
Build fast and execute immediately
In order to maintain a quick release cadence, build and test execution times should be optimized. CI/CD build tools should use caching layers where appropriate to avoid expensive computations for static. Tests should be optimized to use appropriate stubs for third-party services.
In conclusion.
Trunk-based development is currently the standard for high-performing engineering teams since it sets and maintains a software release cadence by using a simplified Git branching strategy. Plus, trunk-based development gives engineering teams more flexibility and control over how they deliver software to the end user.
Kev is a lead full stack web developer and serial entrepreneur with over a decade of experience building products and teams with agile methodologies. He is a passionate contributor, author, and educator on emerging open source technologies like DevOps, cryptocurrency, and VR/AR. In his free time, he participates in indie game development jams.