tgoop.com/cto_order_from_chaos/29
Last Update:
На заре своего становления как программиста я использовал trunk-based development (TBD).
Если это подходит для Гугла, Нетфликса и Фейсбука, с их тысячами коммитов в день — подойдёт и для меня. Логично же. Там не тупые ребята сидят, между прочим.
Я проработал так примерно полгода, пока на проект не пришли ещё два трейни.
И этот ваш TBD оказался полной хренью. Ну неудобно же! Постоянно конфликты, постоянно что-то отваливается. Кто это вообще придумал?
Мы тут с тремя коммитами справиться не можем, а они в своём Гугле тысячу в день льют...
В общем, мы посовещались — и перешли на GitFlow.
А всё почему?
А всё потому, что мы неправильно понимали TBD.
Оказалось, что это не ARAM (All Random All Master).
Если ты пушишь в мастер по вечерам, а утром пуллишь обратно — это не TBD.
Даже если ты пушишь с ребейзом, запустил тесты локально, делаешь merge request вместо прямого пуша в мастер — это все равно не trunk-based development...
Сейчас trunk уже нельзя представить без Merge Queue / Train — чтобы никто не ломал master.
- Без быстрого CI/CD — иначе ваши частые мержи будут висеть на длинных пайплайнах. (А если нет частых мержей, зачем вообще брали trunk?)
- Без feature flags — иначе вы не сможете запушить незавершённые фичи или быстро отключить фичу в случае фейла.
- Без короткоживущих, атомарных, итеративных веток — иначе получите большой дрейф и конфликты. Короткие MR — это основа trunk-ритма.
- Без быстрых автотестов (unit + integration) на каждый мерж.
- Без observability и алертов. (Формально это про CD Maturity, но я готов спорить до хрипоты, что это неотъемлемая часть любого флоу.)
Вот и получается, что trunk — это не про одну ветку и не про “пушим в мастер”,
а про зрелость команды и процессов, без которых всё превращается в ARAM и merge-hell.
Если у тебя эталонный trunk — похвастайся, бахни 😇 (если только на словах — 👻)
#GitFlowRelease
BY CTO: Порядок из хаоса
Share with your friend now:
tgoop.com/cto_order_from_chaos/29