Почему Trunk based development вместо Git Flow?

Не нравится Git Flow? Хочется быстро делать релизы? Тогда этот разбор методологии git - Trunk based development для вас.

⚡ Мои курсы

Разделы видео:
0:00 - Введение к уроку
0:19 - Что такое Trunk based development?
1:20 - Main / master / trunk
2:21 - Внесение изменений
4:04 - Feature / entity change
5:16 - Feature flags
8:13 - Примеры изменений
10:44 - Release ветка
11:34 - Плюсы и минусы и сравнение с GitFlow
17:10 - Заключение

[wxuuglq]

Наверное стоит сделать отдельно видео по имплементации feature flags.

[anzay]

Так вот откуда лапшекод берёт вдохновение.

[a.inozemtsev]

Звучит интересно, но в жизни всё иначе) Примерно в 75% случаях, как по мне..
Но спикеру лайк 👍🏻

[maximkozlov]

Ну в целом, такая методология больше вносит проблем, чем даёт преимуществ. Во-первых, фичами управлять мягко говоря не просто и не везде это нормально будет работать, а по большей части я бы сказал, даже не будет работать совсем. Потом мерджить в код недоделанные фичи мягко говоря большая ошибка, потому что не все новые фичи могут быть доделаны в принципе и че с ними дальше делать в кода не совсем понятно. Автор молодец :) материал хороший

[fozliwu]

Не упомянут самый сложный аспект TBD, процентов в 70 от общих проблем методологии. Это изменение в схемах данных и миграции. Как накатывать, откатывать в срезе канареечных релизов.

[IvanKleshnin]

Как делать Feature Toggle для типов TypeScript? Экпорты типов не могут быть условными (по определению это статика).
Можно громоздить type inference но потом её придётся убирать отдельными "очищающими" коммитами.
Как делать Feature Toggler для зависимостей? Городить велосипеды вокруг package.json не хочется. Больше рисков чем профита.
В итоге, как обычно, всё просто в теории и почти нереально на практике :) Это не критика автора, конечно, – спасибо что поднимаете тему.

[alex_chugaev]

I want to emphasize one important difference.

*GitFlow aimed on work in isolation.* And yes, as consequence, you can effortlessly abandon some changes made in a separate branch, for example, some experiment. But, to be fair, it also possible to do with TBD if you use a separate branch for experiment. The downside is the longer you branch lives the more it differs from the main.

*Trunk-based development is about collaboration* with a minimal lag. All devs or even teams working on the latest version of the app.

[dzen]

Ещё кстати с покрытием кода при автотестах будут сложности, надо будет прогонять с разными комбинациями фиче-флагов (причем иметь эти же фиче-флаги и в автотестах), и мержить покрытие от всех прогонов. Щас в CI/CD модно становится, чтобы покрытие кода в Unit тестах увеличивалось с каждым MR, иначе пайплайн для MR фейлишь ) И вот на каждый пуш для этого MR надо будет кучу вариантов юнит тестов прогонять с разными флагами )

[MrMrZetek]

Почему Feature Flags не могуть храниться в БД и менеджиться из админки приложения к примеру?

[sergeyvershinin]

удивительные рекоментации ютуба. среди привычных мне юмористических шоу выдало ваше видео :)

у нас (<10 человек) используем в чём-то похожий подход, только ветки живут по-дольше (порядка недели). к фича-флагам прибегать приходится довольно редко. ещё из того, что не услышал в видео: часто делаем rebase ветки на "свежий" main, если нужно реюзать что-то, что уже выкатили (тут из минусов появляется force push, но особо проблем не доставляет, т.к веткой пользуется один разработчик)

[dzen]

А ещё непонятно как рефакторинги через это все проводить. Когда реально крошишь большой файл на мелкие и что-то серьезно ренамишь. Видимо в этом случае отступаешь от trunk based, и какое-то время работаешь по старинке с develop, и планируешь работу, чтобы никто main без нужды не трогал. Может этот trunk based как временный всплеск на фоне обычного git flow может иногда проскакивать в репе, но не как что-то постоянное.

[gsmsqdk]

Антон, привет. Как идея для видео хм... наверное всем будет интересно - анализ нового рантайма Bun

[uncle-xxi]

У нас на проекте trunk-based flow, спокойно закатываем фича-ветки которые живут и месяц и два. Просто их нужно регулярно ребейзить и перегенерировать миграции. Я до кучи еще сквошу коммиты в ПР после прохождения ревью, чтобы если нужно черипикать в релиз, то пикать один коммит, а не стопицот и резолвить миллиард конфликтов.

[dzen]

Что-то сходу кажется, что и проблемы надуманные, и решение - код-лапша.
Чтобы ревью было удобно съедать по кускам - надо строить флоу, чтобы в каждом коммите были небольшие, но самодостаточные изменения. Тогда весь MR можно посмотреть как совокупность коммитов, которые смотришь по очереди.
С трудом представляю большую команду, где 150 фичефлагов висят в разных местах, и каждый должен знать какие фиче флаги он должен включить, чтобы переиспользовать какие-то куски других.
Для переиспользования хочется выделить общую фиче ветку. И от неё уже базировать все фичи, зависящие от этого кода. Чего-то неправильного в базировании от фиче-ветки не вижу. Обычно это ветка для Эпика, например.
А уж иметь 23 имплементации класса/интерфейса, в котором сейчас идет запиливание 23х фич и соответственно 23 варианта микросервисов (или вариантов объекта с фабрики объектов) с возможностью переключения между ними тащить, а потом ещё и мержить их все после тестов - вообще сложно получается. Тогда уж в одной имплементации класса эти фиче флаги проще запиливать. Да и просто двойное тестирование - сначала с включенным фиче флагом, а потом ещё раз, чтобы проверить, что правильно его убрал.
Интересно докладики на конфах как кому зашел этот метод поискать ) Вроде как сам Фаулер про этот метод на полном серьезе говорит, надо поизучать.

[NO]

У людей, которые говорят, что гит флоу говно, код пованивает, вот они и не разобрались откуда запах