Продолжаем рассказывать про feature flags (FF) – переключатели в коде, которые запускают и деактивируют функции продукта. На этот раз хотим вам рассказать про наше решение – портал фиче-флагов, который позволяет бизнес-заказчикам управлять состоянием FF, а значит функциональностью продукта.
В нашей первой статье про Feature Flags мы говорили, как этот инструмент помогает ускорить запуск новых фич, повысить конкурентоспособность продукта и в целом упростить процессы в команде. Сейчас мы запустили в опытно-промышленную эксплуатацию портал для управления фиче-флагами. И хотим рассказать вам об этом решении.
Feature Flag - это IF-блок, который запускает часть кода при выполнении некого условия. Самое простое – разработчик сам прописывает, включать или выключать код. Могут быть параметры посложнее: например, по расписанию или только для пользователей с такими-то уровнем доступа. Или наоборот – фича отключается, если нагрузка на систему превышает заданный порог.
Идея портала для фича-флагов состоит в том, чтобы владельцы продукта могли самостоятельно вводить в бой или же выключать функции, не привлекая к этому команду разработки. На портале заказчик видит только функции, готовые к приемке и внедрению. Для него это руководство к действию – протестировать, либо включить функциональность. И в нужный момент он самостоятельно переключает её флаг, и функция начинает работать в продукте.
Команде разработки такая механика помогает менять стиль работы: переходить к микрорелизам и выносить за его пределы согласования поставки с заказчиком. Задача выкладывается на прод сразу по факту готовности. Заказчик же управляет приемкой и включением фич на проде. Все делают свою работу, не блокируя друг друга.
Базовый набор функций позволяет переключать флаги и централизованно контролировать состояние всех фич. В дальнейшем мы планируем добавить возможность удалять неактуальные флаги из списка, группировать их по разным фильтрам, выводить аналитику. Фичи можно будет запускать с настраиваемыми параметрами – например, указывать дату, когда она должна включиться или отключиться.
Как портал помогает бизнес-заказчику
A/B-исследования и бета-тесты. В логику переключателей можно заложить стратегию деления пользователей – часть аудитории увидит новую функциональность, а остальные будут работать с основной версией.
Разграничение доступа к функциям. Переключатели могут автоматически открывать и блокировать возможности для разных пользователей. Например, подключать платные функции или запускать пробный режим для новых клиентов.
Защита от сбоев. Системные переключатели позволяют включать и выключать целые компоненты продукта. Например, если нагрузка превышает некий критический уровень или проблемы начинаются во внешнем сервисе, который подключен к вашему продукту.
В конечном счете переключатели приближают управление продуктом к нуждам бизнеса. Имея под рукой простой переключатель функций, заказчик обеспечивает себе оперативный контроль над состоянием продукта.
Архитектура портала
MVP-версия нашего портала представляла собой простую веб-страницу, где отображались статусы функций продукта. Настройки хранились в простом конфигурационном файле.
Когда идея прижилась, MVP вырос до компактного продукта из четырёх модулей:
Микросервис для управления переключателями – содержит в себе всю логику их обработки. Микросервисы получают конфигурацию флагов при старте из configMap для своего namespace и сохраняют в своей локальной памяти. Если происходит включение или включение флагов на страничке портала, то агент меняет все configMaps, а микросервисы через обратную связь обновляют свою локальную конфигурацию.
Фронтенд-модуль – обеспечивает механику включения и выключения переключателей.
Агент – обеспечивает консистентность данных в локальном хранилище, которое заменило конфиг-файл с настройками.
Стартер (опциональный компонент) – позволяет проверить работоспособность каждого отдельного переключателя перед изменением состояния.
Панель управления:
Самое главное, наш портал – это Cloud Native продукт, который изначально разрабатывался для использования в микросервисных приложениях в инфраструктуре Kubernetes. Так что он может работать с любыми продуктами, вне зависимости от платформы, на которой он написан.
Хотите посмотреть вживую – обращайтесь
У нас есть готовые SDK для .NET и Java, с которыми наши команды могут быстро запустить логику работы с фича-флагами в своих продуктах. Это включает в себя не только механизм их переключения, но и верхнеуровневый контекст использования. Например, чтобы состояние фичи не переключилось в тот момент, когда с ней работает пользователь, и не произошёл сбой процесса. А нашим заказчикам эти SDK открывают возможность поэкспериментировать с порталом в своём продукте.
lleo_aha
Иииии потом у тебя legacy монолит и ты туда легко и непринужденно (по всему проекту) рассовываешь этот фича флаг (~неделя работы) а после успешной обкатки ещё неделю его отовсюду выгребаешь
serginho
И это не говоря о том, сколько мусора в код приходит.
Одна фича может быть разбросана по 20и файлам по одной строчке, и везде будут ифы.
Фичи могут частично переплесекаться, что вводит дополнительную сложность в код, которые еще и тестами надо покрывать.
gecube
к сожалению, это так. Я уже говорил о том, что FF требуют аккуратного обращения и дисциплины, а то будет как с Knight Capital
true_engineering Автор
как любой инструмент, флаги нужно применять с умом — и продукт надо подготовить, и команду обучить. в прошлой статье мы приводили схему, как мы сами встроили флаги в микросервисную архитектуру — https://habr.com/ru/post/543420/