Перевод статьи «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 года в этой базе было:
- 1 миллиард файлов
- 2 миллиарда строк кода
- 86 терабайтов контента
- 45000 коммитов в день
- 15 миллионов измененных строк в 250000 файлов еженедельно.
При работе над этой кодовой базой они применяли TBD, и для их нужд этот подход отлично работал. Поскольку в Google работает много талантливых (и, что более важно, — опытных) инженеров, они редко ломают свои сборки.
Также в Google существует очень строгая процедура тестирования (почитать о ней можно здесь). При применении TBD эта процедура тестирования делает возможной быструю и эффективную поставку ПО.
TBD также хорошо сочетается с Agile-методологиями, предполагающими частые поставки для быстрого получения фидбэка от пользователей или клиентов. С TBD вы можете непрерывно интегрировать изменения и получать хорошие снимки текущего состояния кодовой базы.
Давайте коротко обсудим преимущества TBD.
Преимущества TBD
- Фидбэк (от тестировщиков или коллег) поступает быстро, поскольку свой код вы мержите ежедневно. Это делает невозможной ситуацию, когда вы три недели работали над чем-то не тем (или не так), а затем в самом конце работы получили фидбэк, поняли, что все было сделано неправильно, и в результате пропустили дедлайн.
- TBD имеет одно достоинство ментального характера. Разработчики относятся к trunk как к своему общему коду. Когда разработчик работает над своей фичей в отдельной ветке, он склонен считать этот код своим. Таким образом, TBD способствует развитию культуры коллаборации и активизирует общение.
- Интеграция кода со всеми другими текущими проектами и тикетами происходит на ранних этапах, что способствует повторному использованию кода. Это также избавляет вас от ужасного опыта мержа 9-месячной ветки фичи обратно в trunk.
- Большие проекты со множеством задач принудительно разбиваются на маленькие части, а это облегчает эстимейты и способствует разделению кода на модули.
- Когда многочисленные разработчики работают изолированно, каждый в своей ветке, сложно присматривать за джуниорами. Но если им приходится ежедневно коммитить свой код, вы можете мониторить их работу и помогать при необходимости.
- Подход TBD очень тесно связан с непрерывной интеграцией. Когда у вас множество маленьких инкрементальных коммитов в конечный проект, вы получаете кодовую базу, которая постоянно находится в интегрированном и протестированном состоянии. Количество болезненных мержей сводится к минимуму.
Недостатки TBD
- Повышается шанс сломать trunk и разом остановить работу многих людей. Нужно следить за тем, чтобы код всегда проходил юнит-тестирование и тщательные ревью. Это позволит не терять время, целыми днями откатывая назад коммиты.
- Ваша история коммитов в master будет, скорее всего, весьма многословной. Вам будет труднее определить, где именно что-то пошло не так. Если вас вызовут в три часа ночи, чтобы исправить баг на проде, проявившийся после добавления коммитов в течение предыдущего рабочего дня, — вы предпочли бы иметь дело с одним коммитом, или двумя сотнями?
- Если у вас нет быстрой процедуры сборки, вы будете тратить много времени, ожидая, пока что-то соберется, а ваша команда между тем будет непрерывно добавлять новые коммиты.
- Работая по TBD, вы постепенно добавляете новый код, чтобы сделать что-то новое, но вам также нужно, чтобы «старые» пути, которые вы заменяете, продолжали работать. Из-за этого вам приходится полагаться на feature toggles (обычно из базы данных) для включения и выключения разных вещей. Это может усложнить отладку.
- Когда у вас все время происходят коммиты, нужно постоянно следить за тем, чтобы команда регулярно подтягивала изменения из trunk. В противном случае люди будут создавать помехи друг для друга.
Как релизить программы, применяя TBD
У команды, которая придерживается TBD, процедура релиза будет отличаться от аналогичной процедуры в команде, где используются ветки фич.
Допустим, вы работаете с ветвлением. Когда вы мержите что-то (тикеты, завершенные проекты и т. п.) в master, вы делаете релиз этой основной ветки. В некоторых командах релиз master происходит по расписанию, скажем, раз в неделю.
А вот как обстоят дела с релизами в TBD-командах:
В TBD ответвления используются исключительно для релизов.
Вы делаете «снимок» вашей кодовой базы в ее стабильном состоянии, готовом к деплойменту и релизу.
В приведенной выше схеме могут появиться дополнительные детали, только если с релизом prj-123 что-то пойдет не так. Тогда мы коммитим результат в trunk и выбираем (cherry pick) коммиты в нашу ветку релиза, чтобы как можно быстрее привести ее в рабочее состояние.
В некоторых командах, если релизы у них происходят регулярно, вообще обходятся без ответвлений и, когда необходимо, делают релиз trunk.
Заключение
Теории и практике TBD посвящен отдельный сайт, там вы можете узнать гораздо больше.
Надеюсь, прочитав эту статью, вы поняли, что такое Trunk Based Development и зачем нужен этот подход. Он определенно помогает избавиться от многих проблем, связанных со слиянием долгоживущих веток.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
