Приветствую всех читателей. Меня зовут Роман Доронин. Уже 2,5 года я iOS-разработчик в компании СберЗдоровье. Именно здесь я близко познакомился с понятием фича флага и увидел всю силу этого инструмента. Цель этой статьи — не рассказывать про механизм работы фича флагов, а показать, как можно сделать удобный инструмент управления ими. Поэтому эта статья подойдет тем, кто уже знаком с этим инструментом и знает принципы его работы. Сначала давайте определим немного понятий, чтобы говорить на одном языке — дальше я буду обращаться к ним без подробностей. Я не являюсь последней инстанцией и понятия, которые опишу здесь, определяю по тому, как мы понимаем их у себя в компании. Дебаг меню — дополнительный экран, реализованный в мобильном приложении, который позволяет пользователю просматривать и/или управлять внутренним состоянием программы с целью отладки. Пользователь имеет доступ к этому экрану только в дев сборке приложения. Фича флаг (Feature Flag) — пара: ключ и булевое значение (равное true или false), которое нужно для скрытия от пользователя конкретной фичи, посредством выставления условия в коде. С помощью фича флага также управляется раскатка фичи на пользователей, а конкретно процент раскатки. Фича флаг бывает локальным (хранится и управляется с устройства) и удаленным. Remote Config — набор настроек, которые приходят на устройство при старте приложения. Именно в нем приходят значения удаленных фича флагов. Настраивается и хранится на сервисе для управления удаленными фича флагами. A/B тест — тип тестирования, при котором пользователи приложения случайным образом делятся на сегменты настраиваемого размера. Один из сегментов остается без изменений — это контрольный сегмент «A». На основе данных по этому сегменту будет оцениваться эффект от вносимых изменений. Пользователям из сегмента «B» показывается измененная версия приложения. Если новых вариантов, например, два, то такой тест будет именовать уже A/B/C тестом и т.д.. Далее по набору метрик внесённые изменения оцениваются и принимаются решения. A/B Фича флаг  — по формату очень похож на обычный фича флаг, но имеет возможность принимать множество значений в зависимости от количества сегментов при A/B тесте. Код нашего инструмента фича флагов в том виде, в котором я его застал, был далек от идеального. Но он исполнял одну важную функцию: при заходе в дебаг меню у нас была секция FEATURE FLAGS, в которой было поле Local Feature Flags — по нажатию на него открывался список фича флагов. Напротив каждого фича флага был свитч, который показывал, включен фича флаг или выключен. Локальные фича флаги по умолчанию работали в дев сборке, удаленные — в прод сборке. Все новые локальные фича флаги выключались по умолчанию, но после попадания фичи в релиз, значение по умолчанию изменялось на включен. Это было нужно, чтобы в дев сборке по умолчанию отображалось приложение максимально похожее на прод сборку. В какой-то момент у наших тестировщиков возникла проблема — часто требовалась настройка локальных фича флагов под значения удаленных. Самый яркий пример — регресс. Во время него все нужные фича флаги уже включены удаленно — оптимально, чтобы можно было переиспользовать удаленные фича флаги в дев сборке, но вместо этого тестировщику приходилось заходить в дебаг меню и вручную проставлять еще не включенные локальные фича флаги. Также не было никакой возможности управлять A/B фича флагами локально. В результате передо мной встала задача сделать так, чтобы мы могли в дев сборках: использовать локальные фича флаги, настраиваемые нами; использовать удаленные фича флаги; добавить поддержку A/B фича флагов. Перед началом разработки решения, мы провели опрос и митинги с QA командой — это позволило нам определить перечень функций и инструментов, которые важно внедрить. На основании полученной информации было решено добавить в нашу секцию FEATURE FLAGS в дебаг меню три инструмента и улучшить уже имеющийся. Using remote config В нашем проекте фича флаги бывают локальными и удаленными. Локальные задаются на устройстве и на устройстве же могут быть изменены. Удаленные поставляются с нашего сервиса удаленных фф — в нашем случае это Flagr. Using remote config — булевая переменная, которая указывает, значения каких фича флагов используются: локальных или удаленных. В дев сборке Using remote config по умолчанию выключен, в прод сборке — включен.  Значение Using remote config хранится на устройстве. Feature flag service host type У нас развернуто два сервиса удаленных фича флагов: production и development. Инструмент позволяет переключаться между ними. Это нужно для удобства и вариативности тестирования. На development сервисе можно свободно и безопасно переключать значения удаленных фича флагов для тестирования и разработки. После переключения обязательно нужно перезапустить приложение, чтобы выкачать remote config с выбранного сервиса. Local feature flags Этот инструмент остался практически в первозданном виде. Представляет собой таблицу с указанием всех локальных фича флагов, которые можно включать и выключать. Конечно же, следует перезапускать приложение после смены значений фича флагов для корректной работы. Локальные фича флаги будут работать только в том случае, если Using remote config находится в значении выключен. Также здесь присутствует поиск фича флагов по названию или описанию и кнопка Синхронизировать с удаленными ФФ — по нажатию на нее, локальные фича флаги примут значения удаленных, с того сервиса, который был указан в поле Feature flag service host type. Иногда нужно иметь окружение, такое же как на удаленном проде, но с измененными одним или несколькими флагами, с чем нам поможет эта кнопка. A/B feature status Это новый инструмент для управления A/B фича флагами. Также представляет собой таблицу с указанием всех A/B фича флагов, для которых можно задавать конкретное значение из списка. У каждого A/B фича флага имеется собственный свитч, который указывает, какой А/В фича флаг используется: локальный или удаленный. Так же у А/В фича флагов на экране списка есть индикатор: локальный — красный, удаленный — зеленый. Это дает большую вариативность настройки приложения и его фичей прямо в приложении. Интеграция новых функций и решений позволила максимально быстро, бесшовно и точно решить поставленные задачи. Разработкой инструментов занимался один разработчик, на это ушел один спринт — 2 недели. Все решения, которые мы внесли, достаточно просты, но очень сильно упростили работу тестировщикам и разработчикам. Автоматизировав настройку окружения, мы сэкономили время на рутинных действиях и уменьшили количество пропущенных ошибок. Добавленный набор инструментов на данный момент покрывает все необходимые для тестирования кейсы. Мы уже используем описанные инструменты и работаем над их улучшением.  iOS Developer