Давным-давно, ещё во времена больших сотовых телефонов и динозавров, когда PERL был перспективным языком программирования, наши инструменты были очень простыми и надежными:
PUTTY и FTP были основным способом обмена кодом и ведения совместной разработки.
Разработку вели в одиночку или малыми командами.
Хотфиксы мы катили, сразу редактируя файлы в VIM на prod машинах.
Но всё изменилось с приходом систем контроля версий: GIT, SVN, Mercurial, etc. И появление этих инструментов открыло путь к крупным проектам, большим командам и сложным продуктам.
Нам нужно было адаптироваться. Пришлось учится работать в больших и сложных командах, чтобы создавать классные продукты.
Сегодня я расскажу про свой любимый подход к разработке Trunk Base Development, сравню его с другими моделями ветвления и подсвечу его достоинства и нюансы.
Краткий обзор трёх моделей ветвления: Central Workflow, Git Flow, Trunk Based Development, с акцентом на моего фаворита — Trunk Based Development.
Central Workflow
Просто комит и сразу в мастер. А ветки для слабаков.
В итоге Central Workflow подходит:
Для небольших проектов (pet-проектов).
Для команд из 2-3 разработчиков.
Когда мастер сломан.
Git Flow
Процесс — это все! Сложный процесс со сложной моделью ветвления.
Чтобы было проще, постараюсь изложить процесс в виде цикла разработки фичи:
Для создания фичи, вы создаете ветку feature. Ветвите вы её от ветки develop:
Ветка создана, можно начинать разработку.
Ваша команда долго и упорно готовила фичу — теперь всё готово! Но другие команды разработки тоже делают свои проекты. Допустим, готовые фичи уже слили в develop-ветку, при этом ваша ветка сильно отстала.
[Первый раз] Вы решаете конфликты и сливаете ветку в develop:
Время релиза! Вы решили поделится своей фичей с пользователями. Создаётся ветка release от вашего комита.
Но релиз нужно стабилизировать. В нем есть баги, и конфликтующие фичи. Для этого делаем несколько hotfix. Важно, что делаем мы их в релиз-ветке, потому что планируем выкатить именно её.
Релиз стабилизирован. Сливаем его в master c тегом v1.0.0 и катим на prod. Хотфиксы тоже надо слить в develop-ветку. За это время develop опять ушёл вперед.
[Второй раз] Вы решаете конфликты и сливаете ветку в develop:
На prod мы неожиданно ловим еще несколько ошибок, которые важно пофиксить. Вы делаете хотфикс на prod и ветку v1.0.1.
Но новый хотфикс тоже нужно положить обратно в develop-ветку. За это время develop опять ушёл вперед.
[Третий раз] Вы решаете конфликты и сливаете ветку в develop:
В итоге Git Flow:
Очень сложно и запутано.
Много конфликтов в процессе.
Долгий релизный цикл, который плохо подходит для CI\CD.
Подходит для ПО с классическим релейным циклом (параллельная работа над разными версиями, релиз раз в месяц на дискетах).
Trunk Based Development
Характеризуется всего тремя типами веток и итеративным подходом к разработке фичи (привет, Scrum).
Постараюсь изложить его в виде цикла разработки фичи:
Для создания фичи, вы создаете ветку feature. Ветвите вы её от ветки master:
Делаете несколько комитов, заглушки под фичу и необходимые интерфейсы:
Сливаете фича-ветку в master. Ваш функционал может быть закрыт feature-toggle или if false { ... } — «сырой» функционал не должен быть доступен пользователю.
Важно!
Так как с момента ветвления до момента слияния вашей фича-ветки прошло очень мало времени, master не успеет далеко уйти и у вас будет минимум или полное отсутствие конфликтов при слиянии. При этом вы «застолбили» для своей фичи место, подсветили другим командам, к примеру, интерфейсы, которые планируете имплементить. И другие команды будут сразу учитывать это в своей работе.
А ещё у вас очень маленькие PR\MR, которым можно легко и быстро провести code-review. Знаете же эту классическую проблему — большие PR смотрят долго и некачественно.
У вас может быть организован процесс непрерывного деплоя, или деплоя по расписанию, в prod. Так как в master не сливают сложные и плохо протестированные изменения — master остаётся чистым, готовым к релизам.
Вы продолжаете работать над своей фичей в новой итерации — продолжаете её и углубляете.
Важно, чтобы ваша новая фича-ветка оказалось очень короткоживущей, чтобы ловить минимум конфликтов при слиянии и углубить создание фичи.
В итоге, TBD — это:
Ветки, которые живут несколько дней.
Feature-flags для закрытия «сырого» функционала.
Continuous Сode Review. Код-ревью фича проходит каждую итерацию — дифф маленький, ревью делается быстро.
Чистый мастер, готовый к релизу в любой момент.
Плюсы TBD:
Минимум конфликтов при разработке.
Готовность к релизам в любой момент без подготовки.
Очень быстрая и качественная обратная связь на PR\MR.
Минусы TBD:
Не подходит, если в команде много junior-разработчиков. Ребятам гораздо легче делать\ревьювить готовую фичу целиком, чем разделить работу на этапы и держать прошлые итерации в голове.
Нужно доверять комитерам, иначе будут висеть недоделанные фичи и будет непонятно, кто и когда их доделает.
Если потребуется revert — будет больно. Мастер постоянно бежит вперед и revert функционал спустя пару дней уже тяжело. Проще исправить или удалить руками.
Кому подходит TBD:
Опытным командам с небольшим количеством junior-разработчиков.
Большим командам, которые параллельно работают над большим количеством фич.
Приложениям с долгим циклом регрессивного тестирования.
Проектам с непрерывным релизным циклом.
Для кого TBD не очень хорошо подходит:
Junior-командам.
OpenSource-проектам.
Проектам с жестким (классическим) релизным циклом с отгрузкой софта клиентам на дискетах.
Почему всё же TBD
Time To Market
Использование такого подхода дает огромный прирост к TTM метрике.
Короткоживущие ветки позволяют вам экономить время на конфликты при слиянии, а когда нет конфликтов — и нервы экономишь. Багов после решения конфликтов возникает гораздо меньше.
Фича-тогглы, которыми закрываете не протестированный функционал позволяют вам увереннее катиться в прод, потому что фичу сразу можно отключить. И времени на стабилизацию релиза тратится меньше — все новые фичи изначально под тогглом.
Чистый мастер позволяет вам делать релизы настолько часто, насколько нужно. Релизы перестают быть переполнены фичами, а ещё пропадают «ждуны», которые просят задержать релиз.
Релизы бэкенда-монолита:
Релизы приложений:
В таблицах примеры того, как ускорились релизы в Авито за несколько лет. Цифры не самые свежие, но честные.
Вывод
Все фломастеры на вкус разные, но особенно вкусные те, что цвета Trunk Based.
Для Авито эта модель ветвления подошла лучше всего: она позволила сильно ускорить разработку, внедрить быстрый релизный цикл, меньше ловить конфликтов на слиянии, упростить жизнь разработчикам.
Она гораздо проще, чем многие другие модели, но имеет свои ограничения. Выбирайте с умом!