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

No video

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

Рет қаралды 22,318

PurpleSchool | Anton Larichev

Күн бұрын

Пікірлер: 43

@user-wx2uu1gl1q Жыл бұрын

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

@PurpleSchool Жыл бұрын

👍

@anzay911 2 жыл бұрын

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

@a.inozemtsev 2 жыл бұрын

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

@PurpleSchool 2 жыл бұрын

Спасибо)

@alexlightweight Жыл бұрын

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

@maximkozlov3979 2 жыл бұрын

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

@PurpleSchool 2 жыл бұрын

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

@user-fo8zl6iw9u Жыл бұрын

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

@maximkozlov3979 Жыл бұрын

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

@flatmapper Жыл бұрын

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

@PurpleSchool Жыл бұрын

Спасибо!

@IvanKleshnin 2 жыл бұрын

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

@bubblesort6368 Жыл бұрын

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

@dzen1234 Жыл бұрын

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

@dzen1234 Жыл бұрын

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

@alex_chugaev 2 жыл бұрын

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-fo8zl6iw9u Жыл бұрын

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

@sergeyvershinin312 2 жыл бұрын

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

@PurpleSchool 2 жыл бұрын

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

@alexlightweight Жыл бұрын

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

@dzen1234 Жыл бұрын

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

@user-fo8zl6iw9u Жыл бұрын

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

@dzen1234 Жыл бұрын

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

@user-fo8zl6iw9u Жыл бұрын

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

@dzen1234 Жыл бұрын

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

@viktorg.7896 Ай бұрын

Решается очень просто - для тестового энвайрмента, который используется для каждодневного девелопинга, включаем все фичи. Когда решено, что идем в релиз, деплоим на стейджинг с тем листом фича флагов, который используют кастомеры и раним там тесты которые связаны с конкретными фичами. При этом тестовый фреймворк имеет функциональность скипать тесты которые не предназначены для конкретной новой фичи (aka "runOnlyOnFeature(featureName)"). Таким способом мы в нашей команде делаем деплойменты на прод каждый день.

@uncle-xxi Жыл бұрын

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

@PurpleSchool Жыл бұрын

👍

@ArtyomShakurov Жыл бұрын

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

@dzen1234 Жыл бұрын

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

@user-fo8zl6iw9u Жыл бұрын

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

@dzen1234 Жыл бұрын

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