Почему Trunk Based Development – лучшая модель ветвления. Андрей Александров

Ругаться хочется!
— TBD лучше чем что? Чем git flow? Всегда? А когда нельзя все фичи оборачивать фича-флагам. И как трекать зависимости между фича-флагами? Если, допустим, вы отключили покупки в один клик, и у вас отвалились покупки через apple pay.
А вообще, чем лучше? А мы можем деплоить очень быстро в прод, очень быстро доставлять фичи! А если у нас верификация каждой поставки — месяц? А если деплой в полях на девайсы, не by wire?

Выбор стратегии конфигурационного менеджмента зависит в первую очередь от жизненного цикла проекта, и уже во вторую — от имеющихся процессов и зрелости команды. Не все проекты — интернет-магазины, не все позволяют А/Б тестирование, и делать такие ультимативные заявления — расписываться в собственном узком кругозоре. Что для devops-консультана (а не in-house devops, который, может, одним проектом живет и другого не видал) — вообще равносильно профнепригодности!

— Дальше мы все это можем выпустить в prod и переключить Feature Flags на то, что мы теперь используем новые колеса.
— И новыми pull request’ами удалить старое

Да, хорошо так уметь делать, тогда все получится. Но, как правильно замечено, это не сложно, а «очень-очень сложно». В целом — весьма толковая статья, понравилось.

Статья ниочем и просто пересказ унылых и давно известнызх тезисов, без попытки их анализа, понимания компромиссов и недостатков, которые несет за собой TBD.

У любой фичи есть видимая (бизнес-логика, которую видно в UI приложения, если человек пишет фронтенд, или в UI Postman/Swagger, если бэкенд) и невидимая для бизнеса часть (исследование, рефакторинг, построение или изменение абстракций).
Когда фичу делает один человек (ну или два, три человека, мержа код в один фича-бранч), поработать и над видимой, и над невидимой частью достается всем, а в конце майлстоуна видно, кто, каких и сколько фич сделал.
В предлагаемом же варианте человек может делать исключительно невидимую для бизнеса работу, и несет все риски, связанные с этим (хотя в целом команда работает быстрее).

В описанном экстремальном варианте должен получаться весьма грязный код с кучей мертвых веток. Причем, нетривиально понять какая из веток реально уже не нужна.
В менее экстремальном варианте встречается почти на всех больших проектах. Большие изменения первый раз релизятся под feature flag, в следующий релиз этот flag обращают. — новая ветка становится основной. А потом (когда-нибудь и если) вычищают старый код.

В State Of DevOps 2018 от DORA мы видим, что Нigh Performing компании используют Trunk Based Development. Разберемся, почему именно ее, какие ее преимущества и недостатки имеет эта модель

Очередной какого-культ. Что DORA, что TBD сами по себе ничего не гарантируют. Вы — не Гугл, не Фейсбук и не Яндекс. «Что русскому хорошо, то немцу смерть» Выглядит, что любую практику надо пропускать сквозь фильтр скепсиса и брать из неё только лучшее, а внедрять с умом, не копируя слепо опыт коллег

chemtech как всегда спасибо за то, что он улучшает этот мир, публикуя расшифровки докладов здесь, на Хабре