Вадим Ваганов, ведущий эксперт разработки в Газпромбанке
Привет! Меня зовут Вадим, я техлид команды разработки платформы кеширования в Газпромбанке. Хочу рассказать о том, как внедрили, использовали и улучшали Trunk Based Development, совершили все возможные ошибки, но в итоге получили то, что хотели — быструю и надежную разработку. Cycle time у нас теперь около одного дня, по одному сервису больше 30 деплоев в месяц, и команда больше не боится пятничных релизов.
Если коротко про TBD — это подход к разработке с одной интеграционной веткой (trunk), куда все делают мердж-реквесты несколько раз в день. Никаких долгоживущих feature-веток, никакого git-flow с develop.
Эта история не про теорию — про практику. Расскажу, какие проблемы мы решали, в какие ямы падали и как выбирались. В итоге соберу чек-лист из семи мудростей, которые мы поняли за этот год — надеюсь, они помогут вам избежать наших граблей.
Амбиции и реальность
Мы работаем с высоконагруженным сервисом. Когда тысячи клиентов одновременно заходят в мобильное приложение, нагрузка идет через нас.
Не могу сказать, что наш процесс был совсем плох, но нам нужно было стать быстрее. Поставили себе цель: «от коммита до продакшена за один час».
У нас каждый релиз был болью: пока все тестировал и согласовывали, бизнес терял время, а разработчики — мотивацию: код писать хотели все, а вот релизиться желание падало чем дальше, тем больше. Тогда и решили попробовать внедрить Trunk Based Development.
Звучит просто: создали ветку транк и — все, TBD готов. Но сходу возникла куча проблем: очереди из мердж-реквестов, ветки от веток, полная неуверенность в стабильности транка.
Что такое TBD и чего мы от него хотели
Мы сформулировали четыре хотелки от TBD:
Мердж-реквесты сливаются в основную ветку в течение дня.
Ветки живут максимум несколько дней.
Команда уверена в состоянии транка (если что-то попало в trunk, оно точно ничего не сломает).
Коммиты быстро доставляются на прод.
Звучит красиво. Реальность сложнее.
Четыре главные проблемы нашего пути
Проблема 1: Болото мердж-реквестов
Первое, что случилось — наши мердж-реквесты начали «пахнуть». Образовалась огромная очередь, которую мы просто не успевали разгребать.
Причин было две. Первая — банальная нехватка времени на ревью. Разработчики были заняты «важными» задачами, а ревью казалось чем-то второстепенным.
Вторая — сами мердж-реквесты были в ужасном состоянии. Огромные, разнородные изменения, которые невозможно просмотреть за полчаса.
Срабатывает простая психология: между понятным и непонятным человек всегда выберет понятное. Есть непонятный мердж-реквест, а есть понятная задача — пошел делать задачу.
Проблема 2: Бессмертные ветки
Наши фича-ветки жили намного дольше нескольких дней. Хуже того — началась эпидемия «веток от веток». Один разработчик делает фичу, другому нужна его фича, и получается ветка от ветки.
Проблема 3: Кризис доверия к транку
Даже когда код попадал в транк, мы не были уверены, что ничего не сломали. Пайплайн мог мигать зеленым, но при этом тестов не хватало и очень часто на стейдже все разваливалось из-за того, что мы что-то не учли на стыках.
Проблема 4: Страх деплоя
Последний психологический барьер — страх деплоя на прод. Поднимите руку, кто не деплоит в пятницу.
Семь мудростей TBD
Год экспериментов научил главному: TBD работает, но только если понимать, как именно. Вот семь ключевых инсайтов — каждый решает конкретную проблему, с которой мы столкнулись.
Мудрость 1: Код-ревью — самый важный (почти) приоритет
Мы взяли внутреннюю документацию и расписали приоритеты команды:
Инциденты на продакшене;
Инциденты на стейдже;
Установка готовых поставок на прод;
Код-ревью мердж-реквестов;
Все остальное.
Зафиксировали это в документации команды. Теперь, когда разработчик говорит «я занят, не могу делать ревью», смело говорим ему: «Можешь. По приоритету у тебя сейчас ревью».
Сделали дашборд, где у нас по приоритетам все расположено: инциденты продакшена, инциденты стейджа, неустановленные поставки, код-ревью. По сути, такая игра — «опустоши все корзинки».
Мудрость 2: Автор несет ответственность за мердж-реквест
Есть тайная сущность разработчика: долго делаешь фичу, преодолеваешь проблемы, и когда все готово, хочется побыстрее от этого избавиться. Закидываешь мердж-реквест и думаешь: «Ребят, все, пока. Когда «вольете», сообщите».
Мы инвертировали ответственность. Зафиксировали в документации: за мердж-реквест отвечает его автор. Если он не попадает в транк в течение дня — это проблема автора.
Разница огромная. Когда человек делает код, который удобно проверять — это совсем другой уровень. Он подумал, дал контекст, убрал лишние изменения, разбил на несколько мердж-реквестов. В итоге ревью проходит за 15 минут вместо мучительного часа с тремя итерациями правок.
Мудрость 3: Никаких веток от веток
Установили жесткие правила:
Ветвиться только от транка;
Никаких веток от веток (кроме транка);
Если работаешь в своей ветке — только ты туда коммитишь.
Я как техлид больше всех нарушал последнее правило. Смотришь мердж-реквест, видишь мелкую фигню и думаешь: «Сейчас я сам поправлю». Идешь, коммитишь, а потом видишь — изменения пропали. Потому что автор параллельно форс-пушнул что-то свое.
Еще один лайфхак — мы отказались от релизных веток. Просто релизимся с транка. Законом не запрещено.
Мудрость 4: Декомпозируйте на уровне кода
В GitFlow привыкли: ветвишь фичу и работаешь в ней неделями. В TBD можно по-другому — коммитить кусочки кода.
Добавить модель данных? Отличный мердж-реквест. Маппер? Тоже хорошо. Интерфейс? Вообще красота. Проверять такое — дело нескольких минут.
Возникает вопрос: а что если код не используется или что-то поломает? Тут в дело вступают фича-тогглы — умный if, который выключает новый код. Если тоггл выключен, ваш код для продакшена не существует. Пишете код, он поставляется, но не работает.
Мудрость 5: Распараллеливание через абстракции
Параллелиться можно не только ветками, но и абстракциями. В TBD есть термин Branch by Abstraction — не ветки под каждую абстракцию, а ветвление с помощью абстракций.
Пример из практики. У меня три разработчика:
Паша дорабатывает текущий репозиторий с синхронным драйвером
Даниил пишет новую функциональность, которая зависит от репозитория
Артур хочет сделать новую быструю асинхронную реализацию
Решение простое — делаем интерфейс под репозиторий. Все. Паша работает с тем же кодом, прикрытым абстракцией. Данилу все равно, какая именно реализация — он работает через интерфейс. Артур пишет новую реализацию того же интерфейса.
Звучит банально, но работает.
Мудрость 6: Уверенность через shift-left
Мы перенесли максимум проверок на этап мердж-реквеста — классический shift-left подход.
Мастхэв — интеграционные и компонентные тесты. Они поднимают нужное окружение, но изолируются от других сервисов. Без них постоянно были ситуации: юниты зеленые, логика правильная, а на стыке все разваливается. Spring-контекст не поднимается, или все ломается на стейдже.
Добавили контрактные тесты, подтянули навык написания юнит-тестов. Самое важное — запускаем все это на мердж-реквесте. Если что-то упало — мердж-реквест красный, можно не проверять.
Да, это может замедлить, особенно вначале. Интеграционные тесты могут валиться по разным причинам, но когда пайплайн зеленый — появляется полная уверенность в изменениях. Можно деплоить без страха, что что-то сломается.
Мудрость 7: Деплой — это не релиз
Главное осознание: деплой и релиз — разные сущности. У нас есть фича-тогглы, Branch by Abstraction, сильный пайплайн. Когда деплоимся — просто доставляем код на прод, не доставляем новые фичи.
Чего мы обычно боимся? Что новая фича не заработает, сломает старую. Но если доставляем код, а не фичу — что это может поломать? Кажется, ничего.
Получается, можем деплоить в любой момент. Наш следующий шаг — автоматический деплой на прод. А релизы происходят, когда готовы вы, готовы смежники, когда хорошо протестировали фичу. Когда готовы — включили тоггл.
Главное — в любой момент можем посмотреть на мониторинг, увидеть проблемы и просто выключить фичу. Деплой и релизы становятся безопасными.
TBD рождается в голове
Самая важная мудрость: TBD — это в первую очередь культура, а не инструменты. Можно зайти на trunkbaseddevelopment.com, прочитать практики и начать их бездумно применять. Скорее всего, не сработает.
Работает только когда команда понимает, зачем это нужно. Когда обсуждаете подходы к решению задач, поправляете друг друга в сторону TBD-практик. Видите большой мердж-реквест — предлагаете разбить на несколько. Замечаете ветку от ветки — напоминаете про правило «только от транка». Это становится частью культуры команды.
Чек-лист
Создайте приоритет для ревью — задокументируйте, вшейте в процессы;
Наделите автора ответственностью — за мердж-реквест отвечает тот, кто его создал;
Откажитесь от интеграционных веток — только транк для ветвления;
Декомпозируйте на уровне кода — добавляйте код маленькими частями;
Параллельтесь через абстракции — интерфейсы вместо веток от веток
Сделайте серьезный shift-left — максимум проверок на мердж-реквест;
Разделите деплой и релиз — деплой доставляет код, релиз включает фичи.
Выводы после года с TBD
TBD может ускорить разработку, НО делать придется правильно. И чтобы практика реально заработало, придется менять мышление.
TBD заставит серьезно заняться CI/CD-пайплайном. Когда команда начинает коммитить в основную ветку несколько раз в день, качество и скорость пайплайна становятся критичными. В какой-то момент он станет главным ограничением — команда настолько быстро создает и ревьюит мердж-реквесты, что основное время тратится на ожидание результатов тестов и проверок. Это хорошая проблема — она заставляет оптимизировать пайплайн и делать его быстрее.
В общем, мы уже с трудом представляем, как работать по-другому. До заветного часа «коммит-продакшн» мы пока не дошли, но путь того стоил.