Remote Config: от теории к практике¶

Готовые сценарии использования Remote Config в PWS: управление фичами, персонализация и реагирование на инциденты.

Общие принципы¶

Чтобы работа с Remote Config была предсказуемой и безопасной, важно придерживаться нескольких ключевых принципов. Это фундамент, который позволит избежать хаоса и сделает ваши конфигурации надежными.

Именование ключей: вводим порядок¶

Когда параметров становится много, без строгой системы именования легко запутаться. Используйте префиксы для группировки ключей по назначению — это упростит навигацию и управление. Например:

feature_ — для флагов, управляющих функциональностью (feature_newOnboarding_enabled).
ui_ — для настройки элементов интерфейса (ui_mainScreen_banner).
service_ — для конфигурации внутренних сервисов (service_api_timeout).
limits_ — для динамических ограничений (limits_fileUpload_maxSizeMb).
integration_ — для управления внешними интеграциями (integration_paymentGateway_enabled).

Выбор типа данных и значения по умолчанию¶

Правильный выбор типа данных — половина успеха.

Boolean: Идеален для простых переключателей «включено/выключено».
Number: Используйте для таймаутов, лимитов и любых числовых констант.
String: Подходит для передачи коротких текстов или для выбора одного из нескольких вариантов логики.
JSON: Незаменим для сложных, структурированных данных.

Ключевая практика: всегда реализуйте в коде приложения значение по умолчанию для каждого параметра. Это ваш страховочный трос, который защитит пользователей от сбоев, если параметр будет удален или вернется с ошибкой.

Роли и ответственность: командная работа¶

Процесс изменения конфигурации — это командная работа с четким разделением ответственности:

Подготовка: Remote Config Editor или Remote Config Admin создает и редактирует черновики. Важно: пока изменения находятся в статусе черновика, API продолжает возвращать последнюю опубликованную версию параметра. Если параметр новый, API не вернет его до первой публикации.
Публикация: Remote Config Editor или Remote Config Admin публикует проверенные изменения, делая их доступными для всех пользователей.

Актуальность параметров: боремся с техдолгом¶

Временные конфиги имеют свойство становиться постоянными. Чтобы этого избежать, договоритесь «на берегу» об условиях, при которых флаг будет удален из кода и из PWS. Это предотвращает накопление технического долга.

Сценарий 1: Сезонные баннеры и темы¶

Задача: Управлять маркетинговыми кампаниями, праздничным оформлением и специальными предложениями, не привязываясь к циклам релиза.

Когда применять¶

Запуск краткосрочных акций («Черная пятница», «Киберпонедельник»).
Отображение информационных баннеров (например, о плановых технических работах).
Динамическое изменение темы оформления приложения к праздникам.

Какие параметры создать¶

Для темы:
- Ключ: ui_appTheme_name
- Тип: String (например, "default", "new_year", "halloween")
Для баннера:
- Ключ для включения: ui_mainScreen_promo_enabled
- Тип: Boolean
- Ключ для данных: ui_mainScreen_promo_config
- Тип: JSON
- Структура JSON: должна содержать только данные — заголовок, текст, URL изображения, ссылка для перехода (CTA), а также опциональные startDate и endDate для управления периодом показа. Пример:
```
{
  "title": "С Новым годом!",
  "text": "Пусть 2025 год принесёт радость и новые возможности 🎉",
  "imageUrl": "https://example.com/images/ny_banner.png",
  "ctaUrl": "https://example.com/promo/newyear",
  "startDate": "2025-12-20T00:00:00Z",
  "endDate": "2026-01-10T23:59:59Z"
}
```

Как готовить и публиковать¶

Заранее: Editor или Admin готовит конфигурацию баннера в ui_mainScreen_promo_config и публикует ее. Флаг ui_mainScreen_promo_enabled при этом имеет значение false.
Публикация: В момент старта кампании ответственный сотрудник публикует изменение для ui_mainScreen_promo_enabled, устанавливая его в true.

Как запускать/останавливать¶

Запуск: Публикация значения true для флага ui_mainScreen_promo_enabled. Приложение, видя флаг, запрашивает ui_mainScreen_promo_config и отображает баннер. Альтернативный сценарий — приложение само начинает показ, когда текущая дата входит в диапазон startDate/endDate из конфига (при флаге true).
Остановка: Публикация значения false для флага ui_mainScreen_promo_enabled. Это самый надежный способ. Приложение немедленно скроет баннер, игнорируя его конфиг.

Так может выглядеть промо-баннер в приложении, полностью управляемый через Remote Config:

Анти-паттерны¶

Управление логикой через пустые значения: Не используйте публикацию пустого JSON или строки для отключения функции. Это неявный и хрупкий контракт. Всегда используйте для этого отдельный Boolean флаг.
Захардкоженные тексты: Не вшивайте тексты и ссылки в код. Это лишает вас гибкости.
Чрезмерный JSON: Не пытайтесь поместить в JSON логику или верстку. Он должен содержать только данные, а не инструкции по их отображению.

Сценарий 2: Kill-switch для внешней интеграции¶

Задача: Мгновенно отключить интеграцию с внешним сервисом, когда что-то пошло не так, не дожидаясь релиза.

Когда применять¶

Это ваш «красный рубильник» на случай инцидента. Типичные триггеры:

Внешний сервис недоступен или возвращает аномально высокий процент ошибок.
Интеграция создает критическую нагрузку на вашу инфраструктуру.
Обнаружена уязвимость, требующая немедленного отключения сервиса.

Какие параметры создать¶

Ключ: integration_myPaymentGateway_enabled
Тип: Boolean
Значение по умолчанию (в коде): true. Мы исходим из того, что сервис в штатном режиме должен работать.
Значение в PWS: true (включено) / false (отключено).

Как готовить и публиковать в PWS¶

Заранее: Параметр integration_myPaymentGateway_enabled со значением true должен быть создан и опубликован еще на этапе разработки интеграции. Приложение должно быть спроектировано с учетом этого флага.
При инциденте: Editor или Admin создает черновик, меняя значение на false.
Публикация: Ответственный сотрудник (Editor или Admin) публикует черновик. Изменение немедленно распространяется на всех клиентов.

Как запускать и откатывать¶

Отключение: Публикация значения false глобально отключает интеграцию.
Включение (откат): После того как проблема решена, создается и публикуется новый черновик со значением true.

Анти-паттерны¶

Отсутствие фолбэка в приложении: Отключить интеграцию — это полдела. Если приложение не умеет корректно обрабатывать это отключение (например, просто падает или зависает), kill-switch становится бесполезным. Всегда должен быть предусмотрен сценарий-фолбэк.
«Вечные» флаги: Если интеграция выведена из эксплуатации навсегда, удалите флаг из PWS и вычистите связанный с ним код.

Что дальше: расширяя горизонты¶

Текущие возможности Remote Config уже позволяют решать широкий круг задач, от управления релизами до проведения маркетинговых кампаний. Однако мы не останавливаемся на достигнутом.

В будущем вы сможете настраивать конфигурации для конкретных групп пользователей (например, по версии приложения или поведению) и проводить A/B-тесты. Следите за обновлениями в нашем роадмапе.