Вадим Ваганов, ведущий эксперт разработки в Газпромбанке

Привет! Меня зовут Вадим, я техлид команды разработки платформы кеширования в Газпромбанке. Хочу рассказать о том, как внедрили, использовали и улучшали Trunk Based Development, совершили все возможные ошибки, но в итоге получили то, что хотели — быструю и надежную разработку. Cycle time у нас теперь около одного дня, по одному сервису больше 30 деплоев в месяц, и команда больше не боится пятничных релизов.

Если коротко про TBD — это подход к разработке с одной интеграционной веткой (trunk), куда все делают мердж-реквесты несколько раз в день. Никаких долгоживущих feature-веток, никакого git-flow с develop.

Эта история не про теорию — про практику. Расскажу, какие проблемы мы решали, в какие ямы падали и как выбирались. В итоге соберу чек-лист из семи мудростей, которые мы поняли за этот год — надеюсь, они помогут вам избежать наших граблей.

Амбиции и реальность

Мы работаем с высоконагруженным сервисом. Когда тысячи клиентов одновременно заходят в мобильное приложение, нагрузка идет через нас. 

Не могу сказать, что наш процесс был совсем плох, но нам нужно было стать быстрее. Поставили себе цель: «от коммита до продакшена за один час».

У нас каждый релиз был болью: пока все тестировал и согласовывали, бизнес терял время, а разработчики — мотивацию: код писать хотели все, а вот релизиться желание падало чем дальше, тем больше. Тогда и решили попробовать внедрить Trunk Based Development. 

Звучит просто: создали ветку транк и — все, TBD готов. Но сходу возникла куча проблем: очереди из мердж-реквестов, ветки от веток, полная неуверенность в стабильности транка. 

Что такое TBD и чего мы от него хотели

Мы сформулировали четыре хотелки от TBD:

1. Мердж-реквесты сливаются в основную ветку в течение дня.

2. Ветки живут максимум несколько дней.

3. Команда уверена в состоянии транка (если что-то попало в trunk, оно точно ничего не сломает).

4. Коммиты быстро доставляются на прод.

Звучит красиво. Реальность сложнее.

Четыре главные проблемы нашего пути

Проблема 1: Болото мердж-реквестов

Первое, что случилось — наши мердж-реквесты начали «пахнуть». Образовалась огромная очередь, которую мы просто не успевали разгребать.

Причин было две. Первая — банальная нехватка времени на ревью. Разработчики были заняты «важными» задачами, а ревью казалось чем-то второстепенным. 

Вторая — сами мердж-реквесты были в ужасном состоянии. Огромные, разнородные изменения, которые невозможно просмотреть за полчаса.

Срабатывает простая психология: между понятным и непонятным человек всегда выберет понятное. Есть непонятный мердж-реквест, а есть понятная задача — пошел делать задачу.

Проблема 2: Бессмертные ветки

Наши фича-ветки жили намного дольше нескольких дней. Хуже того — началась эпидемия «веток от веток». Один разработчик делает фичу, другому нужна его фича, и получается ветка от ветки. 

Проблема 3: Кризис доверия к транку

Даже когда код попадал в транк, мы не были уверены, что ничего не сломали. Пайплайн мог мигать зеленым, но при этом тестов не хватало и очень часто на стейдже все разваливалось из-за того, что мы что-то не учли на стыках.

Проблема 4: Страх деплоя

Последний психологический барьер — страх деплоя на прод. Поднимите руку, кто не деплоит в пятницу. 

Семь мудростей TBD

Год экспериментов научил главному: TBD работает, но только если понимать, как именно. Вот семь ключевых инсайтов — каждый решает конкретную проблему, с которой мы столкнулись.

Мудрость 1: Код-ревью — самый важный (почти) приоритет

Мы взяли внутреннюю документацию и расписали приоритеты команды:

1. Инциденты на продакшене;

2. Инциденты на стейдже;

3. Установка готовых поставок на прод;

4. Код-ревью мердж-реквестов;

5. Все остальное.

Зафиксировали это в документации команды. Теперь, когда разработчик говорит «я занят, не могу делать ревью», смело говорим ему: «Можешь. По приоритету у тебя сейчас ревью».

Сделали дашборд, где у нас по приоритетам все расположено: инциденты продакшена, инциденты стейджа, неустановленные поставки, код-ревью. По сути, такая игра — «опустоши все корзинки».

Мудрость 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-практик. Видите большой мердж-реквест — предлагаете разбить на несколько. Замечаете ветку от ветки — напоминаете про правило «только от транка». Это становится частью культуры команды. 

Чек-лист 

1. Создайте приоритет для ревью — задокументируйте, вшейте в процессы;

2. Наделите автора ответственностью — за мердж-реквест отвечает тот, кто его создал;

3. Откажитесь от интеграционных веток — только транк для ветвления;

4. Декомпозируйте на уровне кода —  добавляйте код маленькими частями;

5. Параллельтесь через абстракции — интерфейсы вместо веток от веток

6. Сделайте серьезный shift-left — максимум проверок на мердж-реквест;

7. Разделите деплой и релиз — деплой доставляет код, релиз включает фичи.

Выводы после года с TBD

TBD может ускорить разработку, НО делать придется правильно. И чтобы практика реально заработало, придется менять мышление. 

TBD заставит серьезно заняться CI/CD-пайплайном. Когда команда начинает коммитить в основную ветку несколько раз в день, качество и скорость пайплайна становятся критичными. В какой-то момент он станет главным ограничением — команда настолько быстро создает и ревьюит мердж-реквесты, что основное время тратится на ожидание результатов тестов и проверок. Это хорошая проблема — она заставляет оптимизировать пайплайн и делать его быстрее.

В общем, мы уже с трудом представляем, как работать по-другому. До заветного часа «коммит-продакшн» мы пока не дошли, но путь того стоил.