Забудьте о локальных if-ах: как централизованные feature flags делают жизнь разработчика проще

Представьте, что вы разрабатываете новую функцию в приложении, но пока не готовы открыть её всем пользователям. Хочется выложить код на продакшн, но оставить функцию «под замком» до поры до времени. В таких случаях на помощь приходят feature flags (по-русски часто говорят «фича-флаги») — специальный механизм переключения функциональности. Проще говоря, фича-флаг – это пара «ключ – значение (обычно булевое)», которая определяет, активна ли та или иная возможность в приложении. В коде это проявляется как условие: если флаг включён, выполняется новая логика, а если выключен – используется старое поведение. С помощью фича-флагов можно не только скрывать незавершённые функции за условными операторами, но и гибко управлять их постепенным запуском для аудитории (например, включать новую фичу только для X% пользователей). На первых порах разработчики часто реализуют флаги «локально» – в виде переменных конфигурации, констант или параметров в коде приложения. Такой локальный флаг хранится и меняется непосредственно в приложении (или на сервере, где оно запущено). Этот подход может сработать в небольшом проекте, но в масштабе команды и множества окружений у него быстро обнаруживаются недостатки. Во-первых, если значение флага жёстко прописано в конфигурации или коде, для его изменения зачастую требуется выкатывать новую версию приложения (то есть делать повторный деплой). Возможность динамически «покрутить тумблер» теряется, и смысл фич-флагов частично сводится на нет. Во-вторых, появляется рассинхрон между окружениями: например, в продакшене новый флаг включён через удалённую конфигурацию, а в тестовой сборке по умолчанию выключен. В итоге тестировщикам приходится вручную приводить локальные значения флагов в соответствие с продакшеном, что неудобно и чревато ошибками. Кроме того, без общего подхода трудно отслеживать, какие флаги существуют в системе, кто и когда их включал, и на что они влияют.

https://habr.com/ru/articles/897376/

#devops #typescript #разработка_программного_обеспечения #feature_toggles

Забудьте о локальных if-ах: как централизованные feature flags делают жизнь разработчика проще

Представьте, что вы разрабатываете новую функцию в приложении, но пока не готовы открыть её всем пользователям. Хочется выложить код на продакшн, но оставить функцию «под замком» до поры до времени. В...

Хабр

Канареечные релизы на Camunda и Togglz

Привет, Хабр! На связи Егор, бэкенд-разработчик из команды Портфолио в Т-Банке. Мы занимаемся актуализацией данных компаний и периодически внедряем новые подходы в наши процессы разработки. В последнее время мы часто выпускаем новую функциональность, используя метод канареечных релизов. Хочу рассказать о том, как мы это делаем. У себя на проекте мы используем Camunda, поэтому в статье разберем, как более безопасно выпускать новые версии bpmn-схемы на прод, минимизируя влияние багов на пользователей. Статья написана с учетом того, что читатель уже знаком с Camunda и имеет опыт разработки приложений на этом движке.

https://habr.com/ru/companies/tbank/articles/875444/

#camunda #kotlin #bpmn #feature_flags #feature_toggles #canary_release

Канареечные релизы на Camunda и Togglz

Привет, Хабр! На связи Егор, бэкенд-разработчик из команды Портфолио в Т-Банке. Мы занимаемся актуализацией данных компаний и периодически внедряем новые подходы в наши процессы разработки. В...

Хабр