OneFlag
Self-hosted сервис управления фича-флагами и remote-config для команд на OneScript и 1С.
Какую задачу решает
Фича-флаг нужен, чтобы отделить выкладку кода от включения функциональности. Без флагов любое изменение поведения требует релиза, а откат неудачной функции означает откат всей версии.
Готовые сервисы вроде Unleash, Flagsmith и LaunchDarkly эту задачу решают, но плохо подходят для закрытого контура: их либо нельзя разместить внутри, либо для этого нужен сторонний стек. OneFlag работает на том же OneScript, что и остальные внутренние инструменты, и не тянет внешних зависимостей помимо пакетов hub.
Ключевое свойство: изменение доходит мгновенно
Обычная схема опроса означает задержку до минуты и постоянный трафик. OneFlag держит один поток Server-Sent Events на клиента: оператор щёлкает тумблер, и подключённые приложения меняют поведение в ту же секунду, без перезапуска и без опроса.
Тот же поток обновляет и другие открытые дашборды, поэтому два администратора видят одинаковое состояние.
Что входит
| Возможность | Реализация |
|---|---|
| Оценка флагов у клиента | Стандарт OpenFeature, провайдер oneflag-sdk |
| Окружения | dev, stage, prod; у каждого своя настройка флага |
| Таргетинг | Правила «атрибут, оператор, значения» с выбором варианта |
| Таргетинг по версии | Сравнение по semver и диапазоны вида >=2.1.0, ^1.2.3, 1.2.x |
| Процентные выкатки | Стабильное распределение через bucketer |
| Типы флагов | boolean, string, number, object с произвольными вариантами |
| Журнал изменений | CloudEvents 1.0, идентификаторы ULID |
| Доступ | JWT в httpOnly-куке для дашборда, ключ в заголовке для SDK |
| Ошибки API | RFC 9457, application/problem+json |
| Наблюдаемость | /healthz, метрики prometheus на эндпоинте из prometheus-metrics, логи logos |
| Дашборд | Шаблоны JinjOS через winow-view, htmx и Alpine.js без сборщика |
| Управление из консоли | Команды serve и flags на autumn-cli |
Чем отличается от альтернатив
- Совместимость со стандартом. Клиенты пишут код против OpenFeature, а не против API OneFlag. Уход с OneFlag на другой сервис не потребует правок в прикладном коде.
- Одинаковая логика на сервере и в клиенте. Правила разрешения значения вынесены в общий класс
FlagEvaluator, который используют и сервер, и SDK. Значение флага не может разойтись между дашбордом и приложением. - Дашборд без сборщика JS. htmx и Alpine.js сервис отдаёт сам, поэтому правка интерфейса не требует ни Node.js в контуре, ни доступа к внешним CDN.
- Хранилище выбирается настройкой. SQLite для одиночной установки, PostgreSQL для команды, JSON-файлы для конфигурации в системе контроля версий. Прикладной код от выбора не зависит.
Ограничения
- HTTPS не поддерживается: платформа не даёт TLS поверх
TCPСоединение, для внешнего доступа нужен обратный прокси. - Роли сведены к одному администратору дашборда и одному ключу SDK; полноценный RBAC не реализован.
- Вебхуки наружу не отправляются, хотя события уже формируются в формате CloudEvents.
- SQLite рассчитан на один узел. Нескольким экземплярам сервиса нужен PostgreSQL, но живое обновление по SSE получат только клиенты того экземпляра, который принял изменение.
Когда OneFlag не нужен
Если флагов несколько и меняются они раз в месяц, достаточно провайдера openfeature с JSON-файлом: тот же прикладной код, но без сервера. Переход на OneFlag позже не потребует правок, поменяется только регистрация провайдера.