Что такое Trunk Based Development и как его используют в компаниях

Что проверяют

Различает ли кандидат модель ветвления и релизный цикл. Для мобильной разработки вопрос особенно предметный: выпущенную сборку нельзя откатить одной кнопкой, поэтому цена сломанной главной ветки и невыключаемой функциональности здесь выше, чем на сервере.

Как отвечать

Суть простая: все работают в одной главной ветке, ветки живут часы, а не недели, изменения вливаются ежедневно. Незаконченная функциональность прячется за флагом или за абстракцией, поэтому главная ветка всегда собирается и годится к выпуску.

Мобильная специфика, которую и ждут в ответе. Из главной ветки режется релизная, сборка уходит в поэтапную раскатку. Исправление сначала попадает в главную ветку и только потом переносится в релизную выборочным переносом коммита, а не наоборот. Флаги должны переключаться удалённо: установленную у пользователя сборку не откатишь, а проверка в магазине занимает часы или дни.

Что нужно, чтобы это работало: быстрая сборка и быстрые проверки (модульные тесты на каждое изменение, инструментальные на слияние и по расписанию), короткое ревью или парная работа, модульная структура проекта ради меньшего числа конфликтов, и договорённость чистить отработавшие флаги.

Где спотыкаются

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

Заводят флаги без удалённого переключателя и без срока жизни. В первом случае выключить проблемную функциональность можно только новым релизом через магазин, во втором код через год превращается в лабиринт условий, которые никто не решается тронуть.

Переносят серверную привычку быстро откатывать релиз. На мобильном откат это новая сборка, новая проверка магазином и обновление, до которого доедут не все пользователи, поэтому релизная ветка и поэтапная раскатка здесь не формальность.