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

Не нравится Git Flow? Хочется быстро делать релизы? Тогда этот разбор методологии git - Trunk based development для вас.
Видео по GitFlow: • Что такое Git flow и к...
⚡ Мои курсы
Все мои курсы: purpleschool.ru
Курсы для тех, кто не из России: www.udemy.com/user/alariplay/
Telegram канал с полезными советами: t.me/purple_code_channel
Разделы видео:
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 - Заключение

[@user-wx2uu1gl1q]

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

[@PurpleSchool]

👍

[@flatmapper]

Потрясающий контент

[@PurpleSchool]

Спасибо!

[@anzay911]

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

[@a.inozemtsev]

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

[@PurpleSchool]

Спасибо)

[@alexlightweight]

Согласен ! Аналогичная ситуация и с архитектурами, на бумаге все красиво, а в жизни обычно встречаются два типа архитектуры: 1) Отсутствие архитектуры как таковой. 2) 150 слоев разных архитектур и 3000 паттернов, потому что "могём". 🤘 При чем по моему опыту первый вариант даже лучше второго, что зачастую не очевидно для большинства ПМов и тимлидов.

[@maximkozlov3979]

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

[@PurpleSchool]

Да, методология подходит только для части проектов и команд. Для управляемого внедрения фич я рекомендую GitFlow.

[@user-fo8zl6iw9u]

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

[@maximkozlov3979]

@@user-fo8zl6iw9u я так понимаю в моей квалификации вы сомневаетесь :) и предполагаете, что моя квалификация не позволяет мне решить проблемы подобного подхода :) но я могу отметить следующее в ваш огород, что читали вы мой комментарий судя по всему по диагонали и не до конца.

[@dzen1234]

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

[@user-fo8zl6iw9u]

Без тестов в TBD вообще нечего делать. Выполнять тесты с разными комбинациями флагов не нужно. Прогонять нужно тесты только на включенных флагах. Новые тесты так же не исполняются пока флаг не включится. При включении новой фичи начинают прогоняться и новые тесты. Устаревшие тесты при этом отключаются/удаляются.

[@dzen1234]

@@user-fo8zl6iw9u Если будешь прогонять тесты только на всех включенных флагах, то пропустишь кейсы, когда функции определяются в одних флагах, а используются в других. И если у клиента уже есть возможность выключать флаги - может быть баг.

[@user-fo8zl6iw9u]

@@dzen1234 я говорю про модель, когда мы разрабатываем и выкатываемся через фича флаги. Если мы даём возможность рулить фича флагами для клиента, то TBD тут уже не причем. И действительно придется тестировать всевозможные комбинации. Независимо от методологии.

[@dzen1234]

У TBD есть свой сайт. И там самый первый пример про фиче флаги - это передача разных параметров командной строки в приложение.

[@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.

[@user-gs6ms6qd3k]

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

[@vovergg]

Поддерживаю.

[@PurpleSchool]

Хм, подумаю нах этим.

[@IvanKleshnin]

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

[@bubblesort6368]

Так не на типы же флаг вешается, а на фичу. Просто нужно писать код так, чтоб он и с фичей и без работал не падая. Где нужно дефолтное значения кинуть, где стабу подбросить а где по условию игнорировать какой-то входной параметр. Например фича логер и если флаг логера вырубить, то методы логера остаются, просто логи не пишутся.

[@dzen1234]

Вам надо динамически, причем, желательно без перезапуска фиче флаги включать и выключать. Если речь идет об изменении интерфейса или просто о перекомпиляции, то мож trunk-based тут неприменим и внесет больше вреда чем пользы. А если он неприменим для каких-то случаев, значит придется как-то комбинировать flow. Т.е. допустим иметь git flow, но где-то юзать и фиче-флаги ) Просто чтобы быстрее в релиз ветку влить.

[@dzen1234]

Нашел ответ тут. Они сначала обобщают интерфейс отдельным PR, а потом уже запиливают фиче-флаги. kzbin.info/www/bejne/nnq6ZqykoJ17jcU&ab_channel=DevOpsMoscow

[@dzen1234]

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

[@sergeyvershinin312]

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

[@PurpleSchool]

У вас получается больше вариация gitflow с одной веткой мастер.

[@alexlightweight]

Пользуйтесь вашим подходом и не слушайте никого, делайте так как удобно вашей команде, а не как модно молодёжно ! А то зачастую насмотрятся умных видео, а потом приходишь на работу, а там 150 слоев абстракций в коде и столько методик и практик применено, что на само написание кода остается пара часов в день. Короче делайте так как удобно вашей команде, а не так как сказал какой то очередной "гуру" на конференции.

[@MrMrZetek]

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

[@PurpleSchool]

Вполне может

[@alex_chugaev]

At best scenario it must be managed through third party service for feature toggles management.

[@dzen1234]

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

[@user-fo8zl6iw9u]

Гуглу, например, зашёл этот метод. И прочим взрослым компаниям. Нет никаких проблем ни с тестами, ни с переключением фич. Все решается.

[@uncle-xxi]

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

[@PurpleSchool]

👍

[@ArtyomShakurov]

git cherry-pick -m 1 [merge-commit rev. number]

[@user-fo8zl6iw9u]

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

[@N5O1]

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

[@adeptusmechanicus5105]

У нас все проекты так работают

[@PurpleSchool]

Не вызывает сложностей и проблем для новых разработчиков?

[@sol-ares]

такая-же история - всегда использовал такой подход