Trunk based development что это
TBD — что это такое? Магистральная разработка программ для ПК
TBD — что это значит в программировании
Основная идея TBD состоит в том, чтобы не использовать объединение отдельных ветвей функции с основной ветвью при раздельной разработке, а применять деление таких функций на небольшие части, которые сразу помещаются в «ствол» разработки и разрабатываются всеми программистами. Если простыми словами, то команда разработчиков программирует без четкого применения деления на отдельные ветви разработки, а целиком работает над конкретной частью.
Магистральная разработка приносит очень важное преимущество перед другими моделями — в ней практически отсутствуют конфликты при слиянии отдельных ветвей общей разработки.
Преимущества TBD
Помимо основного преимущества, описанного выше, TBD-модель — это еще ряд достоинств, которые нужно отметить:
Быстрое развертывание. TBD совместно с конвейером CI/CD дает возможность разворачивать функциональный код непосредственно в самом сердце производства. Это облегчает интеграцию рабочих частей и развертывание самой разработки. Плюс ко всему это дает хорошую возможность в случае обнаружения ошибок «откатить» разработку до рабочего состояния, так как «рабочие состояния» фиксируются.
Высокое качество кода. TBD — это то, что обеспечивает устойчивый и качественный код, начиная с самой базы, а вероятность ошибок сильно снижается. Также эта модель дает возможность использовать «принцип 4-х глаз», когда минимум 2 отдельных программиста просматривают код перед его отправкой в «ствол» всей разработки. Для этого используется парная разработка, когда программисты работают по двое, а не п оо диночке, помогая и проверяя друг друга. При этом ответственность за качество их части кода лежит на них двоих.
Командная работа. Парная разработка улучшает командный дух. Плюс это дает возможность более слабым разработчикам работать с более сильными, тем самым перенимать опыт и становиться лучше. А также общее дело поднимает градус ответственности и коммуникации между членами команды.
Потенциальные недостатки TBD
Помимо достоинств этой модели разработки, у нее есть собственные потенциальные недостатки. Почему потенциальные? Потому что во многих TBD-командах они отсутствуют, но в принципе их наличие не исключено.
TBD — это то, что обладает следующими потенциальными недостатками:
Заключение
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Trunk-Based Development: как мы внедряем разработку на основе главной ветки
В этой статье мы подробно расскажем о том, как мы трансформируем процесс разработки в наших командах.
Trunk Based Development на пальцах
Все релизы в обязательном порядке выходят в ветке Trunk или Master (по-русски – главной ветке). Разработка новых фич ведется в отдельных, коротко живущих ветках, так называемых фича-бранчах (Feature Branches). Разработчик делает ответвление, пишет код в течение одного-двух дней и возвращает ветку обратно в Master.
Принципиально важно всегда поддерживать работоспособность и стабильность Master-ветки. Здесь на помощь приходят Feature Toggles (FT) – специальные переключатели в коде, которые отображают/скрывают элементы решения или приложения. Они встраиваются в код во время разработки, а управление ими происходит через специальный портал. Так мы можем скрыть от пользователя нестабильные и незавершенные функции, пока идет доработка, и это не повлияет на работу приложения в целом.
Автоматическое тестирование и непрерывное Code Review – еще две обязательных компонента TBD. Если все изменения в фича-бранче закончены, их нужно оперативно слить в Master, поэтому проверка кода должна быть приоритетной задачей. Что касается автотестов, то строго говоря, они подходят не для всех задач, и покрывать ими 100% кода не нужно (мы подробно рассказывали об этом в статье про наш опыт внедрения практик SDET). Для каждой конкретной задачи сценарий тестирования прописывается на этапе планирования. Для задач, где автотесты актуальны, код сливается в Master только после их прохождения.
Декомпозиция задач и Short-lived ветки
Все ветки кода, кроме главной, должны иметь короткий срок жизни, максимум – несколько дней. Этого можно добиться за счет мелкой декомпозиции: ветка будет небольшой, если она решает небольшую задачу. Правильная постановка задач на этапе планирования играет очень важную роль, поэтому мы придерживаемся принципа декомпозиции задач INVEST и вводим иерархию задач.
Декомпозиция по INVEST определяет, каким должен быть пользовательский сценарий (user story):
Independent — независимый
Negotiable — написанный понятным языком
Valuable — несущий ценность
Estimable — поддающийся оценке
Small — компактный, не более 40 часов разработки
Testable — тестируемый в широком смысле
Каждую из планируемых задач нужно «прогнать» по всем этим пунктам. Если по результатам выпадает хотя бы один из них, задачу нужно декомпозировать заново.
Иерархия задач
При уменьшении отдельных задач их общее количество возрастает многократно. Правильно расставить приоритеты и не потеряться в этом потоке нам помогает иерархия задач.
Непрерывная поставка и TBD
Конечная цель всех наших внутренних изменений – ускорение и оптимизация стандартных этапов создания IT-решений.
Мы тщательно проанализировали наш процесс разработки и нашли несколько точек потери времени и качества – они могут возникать из-на недоработки на конкретном этапе или из-за проблем между разными этапами.
Недостаточная аналитика и декомпозиция;
Сборка релизов из множества задач;
Длительное ожидание Code Review;
Потери на слияние больших изменений;
Отсутствие обратной связи от потребителей.
Для того, чтобы оптимизировать этот процесс, мы переходим от ручной доставки программного обеспечения к практике так называемой “непрерывной поставки” (Continuous Delivery, CD). Это надежный, контролируемый и максимально автоматизированный процесс с понятными и четко измеряемыми рисками, который:
Учитывает потери на каждом этапе;
Учитывает потери на переходах между этапами;
Может быть собран автоматически на основе метрик трекера.
Как мы внедряем TBD в работу команд
Прежде всего, мы придерживаемся мнения, что внедрение методики TBD имеет смысл только в активно растущих продуктах. Если на данном этапе проекта мы выпускаем по одной правке в месяц и ведем поддержку, TBD не актуально.
В целом, мы не рассматриваем переход на TBD как отдельную задачу, мы стараемся действовать комплексно и включаем в наши проекты несколько платформенных практик сразу – это и переход на единый трекер Azure DevOps, и добавление функций SDET в командах, и внедрение TBD, в том числе.
Наши проекты сейчас находятся на разных стадиях перехода на TBD, от проекта к проекту текущий статус может отличаться достаточно сильно. Но, в любом случае, в каждом из них мы стараемся внедрить важные составляющие CD и TBD, например, правильную декомпозицию задач, написание автотестов и тестирование требований.
Feature Flags и фабрика ПО
Наши команды практикуют подход Trunk Based Development – новый код сразу добавляется в мастер-ветку, сторонние ветки живут максимум несколько дней. А чтобы коммиты не мешали друг другу, разработчики используют фича-флаги (Feature Flags) – переключатели в коде, которые запускают и останавливают работу его компонентов.
Рассмотрим обычную итерацию разработки: планирование, уточнение требований, создание задач в трекере, разработка. По мере готовности задачи разворачиваются на тестовом окружении для проверки, релизная ветка стабилизируется. Потом наконец наступает выпуск, и команда может наконец получить реальную обратную связь от пользователей.
Если вы стремитесь сокращать Time-to-Market, это недопустимо долго. Чем раньше вы получите обратную связь от пользователей, тем скорее вы исправите ошибки, тем меньше времени вы тратите на неудачные идеи, тем больше ресурсов можете уделить идеям удачным.
Чтобы обновления быстрее доезжали до прода, одна итерация должна включать одну фичу. Именно поэтому нужно сокращать срок жизни веток.
Проблемы долгоживущих веток
Конфликты между коммитами (Merge hell). Откладывание релиза, интеграция с внешней системой, прочие внешние факторы могут привести код в нерабочее состояние.
Трудности с шарингом кода. Другим членам команды может потребоваться код из новой ветки, если фичи зависят друг от друга. Приходится стартовать ещё одну ветку только ради доступа к этому коду.
Проблемы тестового окружения. Если тестовый сервер один, а фиче-веток много, параллельно тестировать задачи не получится.
Тяжело откатить изменения. Проблемы после релиза – обычное дело, и если из-за новой фиче-ветки начинаются сбои, разработчикам приходится выбирать между хотфиксом и ревертом, лезть в исходный код, заново выкладывать решение.
Как Trunk Based Development решает эти проблемы
Trunk Based Development (от англ. trunk – «ствол дерева») – метод разработки кода на основе одной главной ветки. В отличие от подхода Gitflow, TBD позволяет разработчикам добавлять новые модули сразу в master. Второстепенные feature-ветки также могут создаваться, но они имеют короткий срок жизни.
Trunk Based Development предполагает только одну ветку для разработки, которая называется trunk. В любой момент эту ветку можно развернуть её на проде, а разработка, как и прежде, идёт в отдельных фича-ветках. Только теперь эти ветки живут не более двух дней.
Все изменения в trunk вливаются через пул-реквесты. Изменения небольшие, поэтому процесс ревью не затягивается. Попадание нового кода в trunk запускает процессы автоматического билда, тестов и развёртывания на необходимые окружения.
Но как вести разработку в одной ветке, если какие-то фичи ещё не готовы, а релиз завтра? Тут нам на помощь приходят Feature Flags.
Как работают Feature Flags
По сути своей, это IF-блок, который запускает кусок кода при выполнении некого условия. Самое простое – разработчик сам прописывает, включать или выключать код. Могут быть параметры посложнее: например, по расписанию или только для пользователей с такими-то уровнем доступа. Или наоборот – фича отключается, если нагрузка на систему превышает заданный порог.
В точке переключения мы обращаемся к переключателю (toggle router), который определяет состояние фичи. Чтобы понять, какой нужен флаг, роутер обращается к его конфигурации и контексту. Первая определяет общую стратегию включения флага (основные условия для его работы), второй включает любую дополнительную информацию (например, имя пользователя, который отправил запрос, текущее время и т.д.).
Как использовать Feature Flags
Технически фиче-флаги работают одинаково, а по способу применения их можно разделить на следующие категории:
Релизные (release toggles): скрывают неготовые фичи, уменьшают количество веток, открепляют запуск фичи от даты деплоя. Основной тип флагов.
Экспериментальные (experiment toggles): используются для A/B тестирования, позволяют таргетировать функции на разные группы пользователей. Таким образом вы можете развернуть новый сервис на Х% аудитории, чтобы оценить нагрузку или собрать первые отзывы.
Разрешающие (permission toggles): открывают доступ к платным фичам или закрытым функциям администратора. Такие флаги могут жить очень долго, быть очень динамичными и менять своё состояние при каждом запросе.
Операционные (ops toggles): отключают ресурсоёмкие функции. Например, так можно регулировать работу приложения на слабых смартфонах или застраховаться от падения производительности при запуске новой функциональности – флаг отключит модуль до того, как тот вызовет критический сбой.
### Что дают Feature Flags
Непрерывная доставка фич со стабильным качеством – возможность отключить нерабочий код снижает риски в релизной версии.
Тестирование новых фич в боевых условиях – фиче-флаги позволяют постепенно внедрять сервисы, контролируя риски при релизе на реальную аудиторию.
Возможность развивать несколько версий ПО параллельно – TBD и фичефлаги позволяют предлагать разные функции разным группам пользователей, при этом поддерживать все эти версии ПО может всё та же одна команда.
Как управлять флагами
Проприетарные решения: LaunchDarkly, Bullet-Train, Unleash. Каждый продукт предлагает какие-то свои преимущества, каждый по-своему удобный. Но за лицензию придётся платить, а гибкость настройки зависит от разработчика системы.
Open source решения: Moggles, Esquilo. Это бесплатные решения, но чтобы они заработали у вас, потребуется над ними поколдовать. Кроме того, придётся подбирать продукт с таким набором функций, который вас устроит.
Собственная система управления: вариант, которым пользуемся мы. Это единственное в своём роде решение, которое целиком нас устраивает. В будущих постах расскажем подробнее.
Как флаги работают у нас
Feature Flags Portal (FF-Portal): Web + REST API приложение для манипулирования состоянием флагов. Напрямую работает с хранилищем флагов.
Feature Flags Storage (FF-Storage): персистентное хранилище с настройками флагов и их статусами.
Kubernetes ConfigMap (FF-configmap): k8s ConfigMap ресурс, который собирается на основе данных, которые хранятся в FF-Storage в удобном формате для конечного приложения. Изменение данных флагов через FF-Portal также влечёт к изменению FF-configmap.
Microservice (MS): Микросервис, который использует FF-configmap как источник конфигурации при старте приложения. При изменений FF-configmap, микросервис делает перезагрузку своей конфигурации.
Приложение считывает конфигурацию флагов с FF-ConfigMap, который монтируется к Pod-у как файл. При изменении ConfigMap, k8s обновит и файл, далее приложение среагирует на изменение файла и перегрузит конфигурацию флагов.
Изменение флагов происходит через портал, который отправляет интеграционное сообщение в шину при обновлении статуса. Компонент Config Updater обновляет значения флагов в FF-ConfigMap через K8S API.
Напоследок о тестировании
Возникает вопрос, как тестировать продукт с фиче-флагами? На первый взгляд, флаги усложняют в этот процесс – если переключателей становится много, то и количество всевозможных состояний резко растёт.
Но не всегда флаги зависят друг от друга. Поэтому мы для релиза тестируем два предельных случая: 1) все новые флаги выключены и 2) все флаги включены.
Практика показывает, что обычно этого достаточно.
Что такое 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? Делитесь в комментариях.