Наверное стоит сделать отдельно видео по имплементации feature flags.
@PurpleSchool Жыл бұрын
👍
@anzay9112 жыл бұрын
Так вот откуда лапшекод берёт вдохновение.
@a.inozemtsev2 жыл бұрын
Звучит интересно, но в жизни всё иначе) Примерно в 75% случаях, как по мне.. Но спикеру лайк 👍🏻
@PurpleSchool2 жыл бұрын
Спасибо)
@alexlightweight Жыл бұрын
Согласен ! Аналогичная ситуация и с архитектурами, на бумаге все красиво, а в жизни обычно встречаются два типа архитектуры: 1) Отсутствие архитектуры как таковой. 2) 150 слоев разных архитектур и 3000 паттернов, потому что "могём". 🤘 При чем по моему опыту первый вариант даже лучше второго, что зачастую не очевидно для большинства ПМов и тимлидов.
@maximkozlov39792 жыл бұрын
Ну в целом, такая методология больше вносит проблем, чем даёт преимуществ. Во-первых, фичами управлять мягко говоря не просто и не везде это нормально будет работать, а по большей части я бы сказал, даже не будет работать совсем. Потом мерджить в код недоделанные фичи мягко говоря большая ошибка, потому что не все новые фичи могут быть доделаны в принципе и че с ними дальше делать в кода не совсем понятно. Автор молодец :) материал хороший
@PurpleSchool2 жыл бұрын
Да, методология подходит только для части проектов и команд. Для управляемого внедрения фич я рекомендую GitFlow.
@user-fo8zl6iw9u Жыл бұрын
В гугле, например, используют TBD (как и во многих других крупных компаниях) и знают как решать "проблемы". Потому что могут себе позволить за счёт квалифицированных специалистов. Но вы и не гугл. Поэтому начинайте с более простых моделей с проблемами немного другого уровня. По мере взросления проектов и команды возможно пересмотрите.
@maximkozlov3979 Жыл бұрын
@@user-fo8zl6iw9u я так понимаю в моей квалификации вы сомневаетесь :) и предполагаете, что моя квалификация не позволяет мне решить проблемы подобного подхода :) но я могу отметить следующее в ваш огород, что читали вы мой комментарий судя по всему по диагонали и не до конца.
@flatmapper Жыл бұрын
Потрясающий контент
@PurpleSchool Жыл бұрын
Спасибо!
@IvanKleshnin2 жыл бұрын
Как делать 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_chugaev2 жыл бұрын
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 от общих проблем методологии. Это изменение в схемах данных и миграции. Как накатывать, откатывать в срезе канареечных релизов.
@sergeyvershinin3122 жыл бұрын
удивительные рекоментации ютуба. среди привычных мне юмористических шоу выдало ваше видео :) у нас (
@PurpleSchool2 жыл бұрын
У вас получается больше вариация 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 может иногда проскакивать в репе, но не как что-то постоянное.
@N5O14 ай бұрын
У людей, которые говорят, что гит флоу говно, код пованивает, вот они и не разобрались откуда запах
@user-gs6ms6qd3k2 жыл бұрын
Антон, привет. Как идея для видео хм... наверное всем будет интересно - анализ нового рантайма Bun
@vovergg2 жыл бұрын
Поддерживаю.
@PurpleSchool2 жыл бұрын
Хм, подумаю нах этим.
@MrMrZetek2 жыл бұрын
Почему Feature Flags не могуть храниться в БД и менеджиться из админки приложения к примеру?
@PurpleSchool2 жыл бұрын
Вполне может
@alex_chugaev2 жыл бұрын
At best scenario it must be managed through third party service for feature toggles management.
@adeptusmechanicus51052 жыл бұрын
У нас все проекты так работают
@PurpleSchool2 жыл бұрын
Не вызывает сложностей и проблем для новых разработчиков?
@Alex-Shohet2 жыл бұрын
такая-же история - всегда использовал такой подход