Что такое Trunk Based Development и как его используют в компаниях
Что проверяют
Понимает ли кандидат связку модели ветвления с доставкой. Для бэкенда на Python вопрос быстро уходит в практику: как катить несколько раз в день, не ломая совместимость схемы базы, и что должно быть автоматизировано, чтобы главная ветка оставалась зелёной.
Как отвечать
Все изменения вливаются в одну главную ветку, ветки живут часы, интеграция происходит по нескольку раз в день, незаконченное скрыто за флагом. Противопоставить стоит модели с долгими ветками разработки и релиза: там боль слияния копится и выстреливает разом, а частота выпусков падает.
Дальше самое важное для бэкенда это совместимость. Схема меняется в два прохода: сначала расширение (добавили колонку, разрешающую пустое значение, пишем и в старое, и в новое место), потом переключение чтения, и только следующим релизом сужение с удалением старого. Каждый шаг совместим с предыдущей версией кода, поэтому выкатка и откат безопасны, а миграция не привязана намертво к одному деплою.
Что держит главную ветку зелёной: проверки формата и линтера на этапе коммита, быстрый прогон тестов на каждый пуш и вынос медленных сценариев в отдельный шаг, независимость тестов от порядка запуска и общей базы, зафиксированные версии зависимостей.
Где спотыкаются
Решают, что без флагов можно обойтись, раз ветка живёт недолго. В итоге в главную ветку едет полуготовая функциональность, и выпуск приходится придерживать, то есть подход теряет весь смысл.
Кладут в один релиз и создание колонки, и удаление старой. Пока обе версии кода работают одновременно (а во время раскатки это так всегда), старый обработчик падает на исчезнувшем поле, и откат уже ничего не чинит.
Считают подход способом ускориться за счёт формальностей. На деле всё наоборот: быстрые надёжные тесты, автоматическая сборка и дисциплина мелких изменений это входное условие, без них частые вливания просто чаще ломают прод.