Что такое feature flags
Feature Flags и фабрика ПО
Наши команды практикуют подход Trunk Based Development – новый код сразу добавляется в мастер-ветку, сторонние ветки живут максимум несколько дней. А чтобы коммиты не мешали друг другу, разработчики используют фича-флаги (Feature Flags) – переключатели в коде, которые запускают и останавливают работу его компонентов.
Рассмотрим обычную итерацию разработки: планирование, уточнение требований, создание задач в трекере, разработка. По мере готовности задачи разворачиваются на тестовом окружении для проверки, релизная ветка стабилизируется. Потом наконец наступает выпуск, и команда может наконец получить реальную обратную связь от пользователей.
Если вы стремитесь сокращать Time-to-Market, это недопустимо долго. Чем раньше вы получите обратную связь от пользователей, тем скорее вы исправите ошибки, тем меньше времени вы тратите на неудачные идеи, тем больше ресурсов можете уделить идеям удачным.
Чтобы обновления быстрее доезжали до прода, одна итерация должна включать одну фичу. Именно поэтому нужно сокращать срок жизни веток.
Проблемы долгоживущих веток
Конфликты между коммитами (Merge hell). Откладывание релиза, интеграция с внешней системой, прочие внешние факторы могут привести код в нерабочее состояние.
Трудности с шарингом кода. Другим членам команды может потребоваться код из новой ветки, если фичи зависят друг от друга. Приходится стартовать ещё одну ветку только ради доступа к этому коду.
Проблемы тестового окружения. Если тестовый сервер один, а фиче-веток много, параллельно тестировать задачи не получится.
Тяжело откатить изменения. Проблемы после релиза – обычное дело, и если из-за новой фиче-ветки начинаются сбои, разработчикам приходится выбирать между хотфиксом и ревертом, лезть в исходный код, заново выкладывать решение.
Как Trunk Based Development решает эти проблемы
Trunk Based Development (от англ. trunk – «ствол дерева») – метод разработки кода на основе одной главной ветки. В отличие от подхода Gitflow, TBD позволяет разработчикам добавлять новые модули сразу в master. Второстепенные feature-ветки также могут создаваться, но они имеют короткий срок жизни.
Trunk Based Development предполагает только одну ветку для разработки, которая называется trunk. В любой момент эту ветку можно развернуть её на проде, а разработка, как и прежде, идёт в отдельных фича-ветках. Только теперь эти ветки живут не более двух дней.
Все изменения в trunk вливаются через пул-реквесты. Изменения небольшие, поэтому процесс ревью не затягивается. Попадание нового кода в trunk запускает процессы автоматического билда, тестов и развёртывания на необходимые окружения.
Но как вести разработку в одной ветке, если какие-то фичи ещё не готовы, а релиз завтра? Тут нам на помощь приходят Feature Flags.
Как работают Feature Flags
По сути своей, это IF-блок, который запускает кусок кода при выполнении некого условия. Самое простое – разработчик сам прописывает, включать или выключать код. Могут быть параметры посложнее: например, по расписанию или только для пользователей с такими-то уровнем доступа. Или наоборот – фича отключается, если нагрузка на систему превышает заданный порог.
В точке переключения мы обращаемся к переключателю (toggle router), который определяет состояние фичи. Чтобы понять, какой нужен флаг, роутер обращается к его конфигурации и контексту. Первая определяет общую стратегию включения флага (основные условия для его работы), второй включает любую дополнительную информацию (например, имя пользователя, который отправил запрос, текущее время и т.д.).
Как использовать Feature Flags
Технически фиче-флаги работают одинаково, а по способу применения их можно разделить на следующие категории:
Релизные (release toggles): скрывают неготовые фичи, уменьшают количество веток, открепляют запуск фичи от даты деплоя. Основной тип флагов.
Экспериментальные (experiment toggles): используются для A/B тестирования, позволяют таргетировать функции на разные группы пользователей. Таким образом вы можете развернуть новый сервис на Х% аудитории, чтобы оценить нагрузку или собрать первые отзывы.
Разрешающие (permission toggles): открывают доступ к платным фичам или закрытым функциям администратора. Такие флаги могут жить очень долго, быть очень динамичными и менять своё состояние при каждом запросе.
Операционные (ops toggles): отключают ресурсоёмкие функции. Например, так можно регулировать работу приложения на слабых смартфонах или застраховаться от падения производительности при запуске новой функциональности – флаг отключит модуль до того, как тот вызовет критический сбой.
### Что дают Feature Flags
Непрерывная доставка фич со стабильным качеством – возможность отключить нерабочий код снижает риски в релизной версии.
Тестирование новых фич в боевых условиях – фиче-флаги позволяют постепенно внедрять сервисы, контролируя риски при релизе на реальную аудиторию.
Возможность развивать несколько версий ПО параллельно – TBD и фичефлаги позволяют предлагать разные функции разным группам пользователей, при этом поддерживать все эти версии ПО может всё та же одна команда.
Как управлять флагами
Проприетарные решения: LaunchDarkly, Bullet-Train, Unleash. Каждый продукт предлагает какие-то свои преимущества, каждый по-своему удобный. Но за лицензию придётся платить, а гибкость настройки зависит от разработчика системы.
Open source решения: Moggles, Esquilo. Это бесплатные решения, но чтобы они заработали у вас, потребуется над ними поколдовать. Кроме того, придётся подбирать продукт с таким набором функций, который вас устроит.
Собственная система управления: вариант, которым пользуемся мы. Это единственное в своём роде решение, которое целиком нас устраивает. В будущих постах расскажем подробнее.
Как флаги работают у нас
Feature Flags Portal (FF-Portal): Web + REST API приложение для манипулирования состоянием флагов. Напрямую работает с хранилищем флагов.
Feature Flags Storage (FF-Storage): персистентное хранилище с настройками флагов и их статусами.
Kubernetes ConfigMap (FF-configmap): k8s ConfigMap ресурс, который собирается на основе данных, которые хранятся в FF-Storage в удобном формате для конечного приложения. Изменение данных флагов через FF-Portal также влечёт к изменению FF-configmap.
Microservice (MS): Микросервис, который использует FF-configmap как источник конфигурации при старте приложения. При изменений FF-configmap, микросервис делает перезагрузку своей конфигурации.
Приложение считывает конфигурацию флагов с FF-ConfigMap, который монтируется к Pod-у как файл. При изменении ConfigMap, k8s обновит и файл, далее приложение среагирует на изменение файла и перегрузит конфигурацию флагов.
Изменение флагов происходит через портал, который отправляет интеграционное сообщение в шину при обновлении статуса. Компонент Config Updater обновляет значения флагов в FF-ConfigMap через K8S API.
Напоследок о тестировании
Возникает вопрос, как тестировать продукт с фиче-флагами? На первый взгляд, флаги усложняют в этот процесс – если переключателей становится много, то и количество всевозможных состояний резко растёт.
Но не всегда флаги зависят друг от друга. Поэтому мы для релиза тестируем два предельных случая: 1) все новые флаги выключены и 2) все флаги включены.
Практика показывает, что обычно этого достаточно.
Feature flags
Фиче-флаги — это настройки, которые позволяют не трогая программистов менять поведение программы, к примеру включать и выключать фичи. Типа вот этому пользователю показываем общих в списке друзей, а тому — нет.
Чаще всего набор фиче-флагов формирует фронтенд, и отсылает на бекенд в момент каждого запроса. Так можно легко ставить a\b тесты — просто выбираем две когорты, одной добавляем фичу, а другой — нет, и смотрим на поведение.
Пример реализации — GitHub, который передает фиче-флаги в HTTP-заголовках. Прямо сейчас в API гитхаба таким образом включается-выключается одновременно 30 фич.
Есть ещё одно очень полезное применение фиче-флагов — полное отключение функций приложения в зависимости от среды. К примеру, у нас ЦРМ есть фича — уведомлять пользователя по СМС о статусе заказа. Но я не хочу, чтобы СМС уходили с тестовых стендов или из CI, даже если кому-то хватит ума прописать боевые ключи на них. Поэтому я делаю фиче-флаг ENABLE_NOTIFICATIONS и включаю его только в переменных окружения на проде. По умолчанию флаг выключен, поэтому где мы ни развернули мой бекенд — он никогда не пошлет сообдщений живым людям, если его явно об этом не попросить.
Меня зовут Федя Борщёв. Пишу для программистов в телеграме — 3 поста в неделю об управлении сложными проектами, хорошем коде и профессиональном развитии. А ещё я в прямом эфире пишу код на ютубе и выкладываю всякое в фейсбук. Подписывайтесь!
Как портал Feature Flags помогает бизнесу управлять ИТ-продуктом
В нашей первой статье про Feature Flags мы говорили, как этот инструмент помогает ускорить запуск новых фич, повысить конкурентоспособность продукта и в целом упростить процессы в команде.
Идея портала для фича-флагов состоит в том, чтобы владельцы продукта могли самостоятельно вводить в бой или же выключать функции, не привлекая к этому команду разработки. На портале заказчик видит только функции, готовые к приемке и внедрению. Для него это руководство к действию – протестировать, либо включить функциональность. И в нужный момент он самостоятельно переключает её флаг, и функция начинает работать в продукте.
Команде разработки такая механика помогает менять стиль работы: переходить к микро-релизам и выносить за его пределы согласования поставки с заказчиком. Задача выкладывается на прод сразу по факту готовности. Заказчик же управляет приемкой и включением фич на проде. Все делают свою работу, не блокируя друг друга.
Базовый набор функций позволяет переключать флаги и централизованно контролировать состояние всех фич. В дальнейшем мы планируем добавить возможность удалять неактуальные флаги из списка, группировать их по разным фильтрам, выводить аналитику. Фичи можно будет запускать с настраиваемыми параметрами – например, указывать дату, когда она должна включиться или отключиться.
A/B-исследования и бета-тесты. В логику переключателей можно заложить стратегию деления пользователей – часть аудитории увидит новую функциональность, а остальные будут работать с основной версией.
Разграничение доступа к функциям. Переключатели могут автоматически открывать и блокировать возможности для разных пользователей. Например, подключать платные функции или запускать пробный режим для новых клиентов.
Защита от сбоев. Системные переключатели позволяют включать и выключать целые компоненты продукта. Например, если нагрузка превышает некий критический уровень или проблемы начинаются во внешнем сервисе, который подключен к вашему продукту.
В конечном счете переключатели приближают управление продуктом к нуждам бизнеса. Имея под рукой простой переключатель функций, заказчик обеспечивает себе оперативный контроль над состоянием продукта.
MVP-версия нашего портала представляла собой простую веб-страницу, где отображались статусы функций продукта. Настройки хранились в простом конфигурационном файле.
Когда идея прижилась, MVP вырос до компактного продукта из четырёх модулей:
· Микросервис для управления переключателями – содержит в себе всю логику их обработки. Микросервисы получают конфигурацию флагов при старте из configMap для своего namespace и сохраняют в своей локальной памяти. Если происходит включение или включение флагов на страничке портала, то агент меняет все configMaps, а микросервисы через обратную связь обновляют свою локальную конфигурацию.
· Фронтенд-модуль – обеспечивает механику включения и выключения переключателей.
· Агент – обеспечивает консистентность данных в локальном хранилище, которое заменило конфиг-файл с настройками.
· Стартер (опциональный компонент) – позволяет проверить работоспособность каждого отдельного переключателя перед изменением состояния.
Самое главное, наш портал – это Cloud Native продукт, который изначально разрабатывался для использования в микросервисных приложениях в инфраструктуре Kubernetes. Так что он может работать с любыми продуктами, вне зависимости от платформы, на которой он написан.
Изолируем микросервисы с помощью Feature toggles в ASP.NET Core. Теория и подготовка
Привет, Хабр! Если вы работаете с микросервисами, то знаете, что они имеют свойство образовывать некоторую связанность. Хорошо, когда связи между микросервисами однонаправленные, но всё становится сложнее, если возникают циклические зависимости.
Такие зависимости приводят к сложностям развертывания, которые можно преодолеть по-разному — например, используя docker compose. Но на локальном компьютере обычно не возникает необходимости поднятия всей инфраструктуры, потому что разработчика для выполнения задачи обычно интересует какая-нибудь конкретная её часть. В этом случае пригодятся средства изоляции микросервисов.
Меня зовут Сергей Прохоров, я техлид бэкенд-разработки в Ak Bars Digital, и давайте вместе рассмотрим, как реализовать такую изоляцию на примере микросервиса веб-API ASP.NET Core. Метод изоляции основан на использовании feature toggles, или переключателей функциональности, о которых и пойдёт речь в двух частях статьи.
Зачем нужна изоляция микросервисов
Потребности в изоляции могут быть разными, вот лишь некоторые из них, которые встречаются в разработке и тестировании.
Для разработки
При онбординге нового сотрудника. В финтехе получение доступа к внешним зависимостям требуют написания служебных записок в службу безопасности (а это может быть не быстро), а в ряде случаев, к некоторым сервисам доступ вообще не может быть предоставлен — шифрование или каналы ГОСТ являются ярким тому примером.
При аудите или анализе микросервиса с целью выявления технического или архитектурного долга. Иногда логика не столь тривиальна и пройтись отладчиком сильно проще трассировки «в уме».
При необходимости оперативно вносить правки (bug fix) с возможностью отладки. Ускоряем отладку, не тратя время на подъем зависимых контуров и настройку взаимодействия с ними.
Чтобы постоянно не поддерживать актуальность долгоживущих веток предотвращать конфликты слияния. Здесь лучше посмотреть статью по ссылке — там эта информация хорошо объясняется.
Для тестирования
Интеграционное и регрессионное тестирование при разработке. Тестирование изолированного микросервиса позволяет разработчику, при внесении правок, самостоятельно и быстро обнаруживать возникающие дефекты в существующем коде.
Тестирование в рамках непрерывной интеграции (CI), которую выполняет агент сборки (build agent). Зачастую в его окружении нет, или даже не может быть, доступа ко всем зависимостям микросервиса, например из-за все тех же требований безопасности или инфраструктурных ограничений.
Тестирование сценариев взаимодействия с зависимостями. Так можно воспроизводить различные варианты без явных вызовов внешней зависимости, получая соответствующий результат используя внутреннюю логику заглушек.
При тестировании микросервиса, когда внешняя зависимость не имеет тестового контура, а использование промышленной версии в таких объемах неприемлемо. Примером могут служить внешние сервисы оплаты, в которые отправлять реальные деньги на нереальные суммы было бы крайне нежелательно.
При эксплуатации staging-контура заглушки нужны для целей тестирования. Сопряжение стейджинга с промышленными контурами чревато для целей тестирования, а сопряжение с тестовыми контурами зачастую неактуально. При этом исходная кодовая база должна быть идентичной production-контуру.
При нагрузочном тестировании, когда число запросов к внешним зависимостям лимитировано по частоте запросов или по их количеству.
Вместо изоляции в этих сценариях применяют различные инструменты, но в тех случаях, когда реализация посредством изоляции будет дешевле, нужно выбирать именно её.
Что такое feature toggles
Переключатели функциональности (feature toggles) или флаги функциональности (feature flags) — это переменные, которые используются внутри условных операторов.
Блоки внутри этих условных операторов могут быть включены или выключены в зависимости от значения переключателя функции. Это позволяет разработчикам контролировать поток выполнения своего программного обеспечения и обходить функциональность, которая не должна выполняться.
Переключатели можно использовать в следующих сценариях:
добавление новой функции;
улучшение существующей функции;
сокрытие или отключение функции;
Переключатели можно сохранить как свойство в файле конфигурации, в виде записи в базе данных или как запись во внешней службе функциональных флагов.
Канареечные релизы
Еще одно преимущество флагов функциональности — канареечные релизы.
Канареечный релиз позволяет разработчикам постепенно тестировать функции на небольшой группе пользователей. Если производительность функции по каким-то причинам не устраивает разработку или бизнес, ее можно откатить во избежание побочных эффектов.
Microsoft.FeatureManagement
Команды для подключения NuGet-пакетов в проекты с использованием dotnet CLI:
или используя диспетчер пакетов Visual Studio:
Поскольку Microsoft.FeatureManagement построен поверх системы конфигурации, он может управляться любым из самых разных поставщиков конфигурации. Это означает, что вы можете управлять функциями из файла appsettings.json, из переменных среды, из базы данных, или выбрать какой-то из большого количества готовых поставщиков или даже реализовать поставщика самостоятельно. Включение и отключение функции просто требует изменения значения в выбранном поставщике конфигурации.
Библиотека Microsoft.FeatureManagement.AspNetCore добавляет для ASP.NET функциональность, которая будет зависеть от заданного режима (включено/выключено):
фильтры действий для удаления действий контроллеров;
методы расширения для условной регистрации маршрутов, глобальные фильтры и промежуточное ПО;
вспомогательные функции тегов для условного скрытия разделов пользовательского интерфейса MVC.
Примеры настройки appsetings.json
Далее в этой и следующей части статьи я на примере разберу все аспекты работы с флагами функциональности.
Создание веб API ASP.NET Core приложения
Создадим приложение, на котором отработаем изоляцию микросервиса с использованием заглушки.
Создаём шаблонное приложение в Visual Studio
Шаг 1. Создаём пустое приложение Веб-API ASP.NET Core
Теперь можно запустить приложение и проверить его функциональность по умолчанию.
Мастер генерации приложения сформировал код контроллера, который генерирует случайный прогноз погоды.
Давайте сделаем так, чтобы приложение получало реальный прогноз с погодного сервиса, а сгенерированный код позже используем для изоляции — сможем переключаться на него с помощью флага функциональности.
Реализуем прогноз погоды
Для получения реальных данных прогноза погоды я выбрал сервис OpenWeather — он бесплатный, у него низкий порог входа и хорошая документация.
Класс конфигурации OpenWeather
Поиск идентификатора города
Чтобы легко жилось не только разработчикам, но и DevOps и QA-инженерам, вместе с ключами конфигурации стоит копировать в appsettings.json и комментарии. Например, так
Каждая библиотека, подключенная к проекту с помощью NuGet, может добавлять новые разделы в appsettings.json . Чтобы исключить случайные пересечения наименований разделов, мы размещаем разделы в качестве подразделов в App.
Для сопоставления значений из appsettings.json в экземпляры классов конфигурации OpenWeatherConfiguration осуществляется настройка в Startup.cs :
Реализация сервиса запросов
Далее объявляется интерфейс и класс реализации сервиса:
Интерфейс и класс реализации сервиса
Регистрация созданного сервиса и настройка фабрики HTTP-клиентов в Startup.cs :
Генерация и сопоставление моделей ответов
Генерация моделей ответа OpenWeather
Можно было бы воспользоваться документацией на сайте и написать модели ответа вручную, но можно пойти простым путём. Немного модифицировав исходный код текста получаем ответ от сервера в виде строки. После выполнения команды контекстного меню «Быстрая проверка» для переменной response, отображается её текущее значение:
Копируем значение в буфер обмена, а затем, остановив отладку и переставив курсор в конец файла, выполняем следующую команду:
Получилась такая структура проекта:
Такой подход к генерации моделей имеет недостатки: в зависимости от текущего значения в тексте могут быть применены целочисленные типы вместо типов с плавающей запятой, или вовсе не будут сгенерированы отдельные классы, если поля имеют значение null. Так что сверка с документацией всё же не будет лишней.
Подключение AutoMapper
Для сопоставления модели ответа OpenWeather и модели ответа контроллера используем NuGet-пакет AutoMapper.
Для такого простого примера это слишком, но в реальных проектах такой способ существенно упрощает разработку, поэтому используем именно его.
Команда подключения NuGet-пакета в проект с использованием dotnet CLI:
или используя диспетчер пакетов Visual Studio:
Класс настройки сопоставления моделей ответов:
Настройка AutoMapper в Startup.cs :
Изменения в контроллере
Как я уже упоминал, позже переиспользуем код, полученный при генерации решения по шаблону.
Чтобы не занимать буфер обмена, перетянем выделенный код контроллера на панель элементов, чтобы затем перетянуть его обратно в редактор при написании заглушки.
Теперь, когда прежний код отложен на панель элементов, код контроллера приводим к следующему виду:
Проверка функциональности приложения
На этом этапе у нас есть готовое приложение. Теперь его можно запустить и проверить боевую функциональность.
Что дальше?
Как видим, приложение работает, но это далеко не всё, что нужно сделать. Теперь нам нужна реализация заглушки, но её мы напишем во второй части статьи. Кроме этого сделаем экспериментальную конечную точку, функциональность которой можно включать или выключать, не останавливая работу приложения. А ещё разберёмся с экстренными ситуациями, которые могут случиться в реальной разработке, и поймём, как этого избежать с помощью флагов функциональности.
А пока спасибо за внимание, мы с коллегами из Ak Bars Digital готовы ответить на все вопросы в комментариях.
Как портал Feature Flags помогает бизнесу управлять ИТ-продуктом
Продолжаем рассказывать про feature flags (FF) – переключатели в коде, которые запускают и деактивируют функции продукта. На этот раз хотим вам рассказать про наше решение – портал фиче-флагов, который позволяет бизнес-заказчикам управлять состоянием FF, а значит функциональностью продукта.
В нашей первой статье про Feature Flags мы говорили, как этот инструмент помогает ускорить запуск новых фич, повысить конкурентоспособность продукта и в целом упростить процессы в команде. Сейчас мы запустили в опытно-промышленную эксплуатацию портал для управления фиче-флагами. И хотим рассказать вам об этом решении.
Идея портала для фича-флагов состоит в том, чтобы владельцы продукта могли самостоятельно вводить в бой или же выключать функции, не привлекая к этому команду разработки. На портале заказчик видит только функции, готовые к приемке и внедрению. Для него это руководство к действию – протестировать, либо включить функциональность. И в нужный момент он самостоятельно переключает её флаг, и функция начинает работать в продукте.
Команде разработки такая механика помогает менять стиль работы: переходить к микрорелизам и выносить за его пределы согласования поставки с заказчиком. Задача выкладывается на прод сразу по факту готовности. Заказчик же управляет приемкой и включением фич на проде. Все делают свою работу, не блокируя друг друга.
Базовый набор функций позволяет переключать флаги и централизованно контролировать состояние всех фич. В дальнейшем мы планируем добавить возможность удалять неактуальные флаги из списка, группировать их по разным фильтрам, выводить аналитику. Фичи можно будет запускать с настраиваемыми параметрами – например, указывать дату, когда она должна включиться или отключиться.
Как портал помогает бизнес-заказчику
A/B-исследования и бета-тесты. В логику переключателей можно заложить стратегию деления пользователей – часть аудитории увидит новую функциональность, а остальные будут работать с основной версией.
Разграничение доступа к функциям. Переключатели могут автоматически открывать и блокировать возможности для разных пользователей. Например, подключать платные функции или запускать пробный режим для новых клиентов.
Защита от сбоев. Системные переключатели позволяют включать и выключать целые компоненты продукта. Например, если нагрузка превышает некий критический уровень или проблемы начинаются во внешнем сервисе, который подключен к вашему продукту.
В конечном счете переключатели приближают управление продуктом к нуждам бизнеса. Имея под рукой простой переключатель функций, заказчик обеспечивает себе оперативный контроль над состоянием продукта.
Архитектура портала
MVP-версия нашего портала представляла собой простую веб-страницу, где отображались статусы функций продукта. Настройки хранились в простом конфигурационном файле.
Когда идея прижилась, MVP вырос до компактного продукта из четырёх модулей:
Микросервис для управления переключателями – содержит в себе всю логику их обработки. Микросервисы получают конфигурацию флагов при старте из configMap для своего namespace и сохраняют в своей локальной памяти. Если происходит включение или включение флагов на страничке портала, то агент меняет все configMaps, а микросервисы через обратную связь обновляют свою локальную конфигурацию.
Фронтенд-модуль – обеспечивает механику включения и выключения переключателей.
Агент – обеспечивает консистентность данных в локальном хранилище, которое заменило конфиг-файл с настройками.
Стартер (опциональный компонент) – позволяет проверить работоспособность каждого отдельного переключателя перед изменением состояния.
Самое главное, наш портал – это Cloud Native продукт, который изначально разрабатывался для использования в микросервисных приложениях в инфраструктуре Kubernetes. Так что он может работать с любыми продуктами, вне зависимости от платформы, на которой он написан.