Ви ввімкнули нову фічу через змінну середовища, передеплоїли сервіс — і виявили баг. Відкат? Знову деплой, ще 15–30 хвилин. Кожен такий цикл розтягує реліз на години, а audit log відсутній — незрозуміло, хто і коли ввімкнув прапорець. Feature Toggle сервер вирішує цю проблему: відокремлює деплой від релізу, дозволяє керувати прапорцями в реальному часі без перезапуску та дає аудит кожної зміни. І що найважливіше — сервер у сотні разів швидше за змінні середовища: ввімкнення фічі через UI займає 0 секунд, тоді як через env variables — 15–30 хвилин.
Feature flags у production — це не if (process.env.ENABLE_NEW_CHECKOUT === 'true'). Це інфраструктура з API, SDK та UI — справжній feature toggle server. Керування прапорцями за допомогою такого feature toggle server (Unleash або Flagsmith self-hosted) дозволяє реалізувати gradual rollout, A/B тестування прапорців та інтеграцію з Kubernetes. Така feature toggle інфраструктура підходить для GitOps підходу (gitops feature flags) та SDK інтеграції прапорців. Self-hosted рішення (Unleash або Flagsmith) розгортається у вашому кластері Kubernetes, зберігає стан у PostgreSQL та віддає метрики в Prometheus. Ми робимо це під ключ: від вибору системи до навчання команди.
Проблеми, які вирішуємо
- Довгий деплой: кожне ввімкнення фічі займає 15–30 хвилин. З сервером — 0 секунд. Релізний цикл скорочується на 40% — економія $15,000 на рік для команди з 10 розробників.
- Відсутність аудиту: хто і коли ввімкнув фічу — незрозуміло. Audit log фіксує всі зміни з timestamp та користувачем.
- Неможливість A/B тестування: без gradual rollout не можна ввімкнути фічу для 5% користувачів та порівняти метрики. З сервером робите це в UI за хвилину.
Як ми це робимо: стек та кейс
Ми використовуємо Unleash або Flagsmith залежно від завдань. Обидві системи Open Source, працюють на PostgreSQL. Розгортаємо в Kubernetes з autoscaling та моніторингом. Приклад production-ready деплою:
---
# unleash-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: unleash
namespace: feature-flags
spec:
replicas: 2
template:
spec:
containers:
- name: unleash
image: unleashorg/unleash-server:5.9
env:
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: unleash-db
key: connection-string
- name: INIT_ADMIN_API_TOKENS
valueFrom:
secretKeyRef:
name: unleash-tokens
key: admin-token
resources:
requests:
memory: "256Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
Unleash вимагає PostgreSQL. Якщо вже є managed RDS або Cloud SQL — підключаємо туди. Окрема БД, окремий user з мінімальними правами. Рекомендуємо hourly бекап + щоденний повний дамп.
Інтеграція SDK у додаток:
import { initialize } from 'unleash-client';
const unleash = initialize({
url: 'https://unleash.internal/api/',
appName: 'payments-service',
customHeaders: {
Authorization: process.env.UNLEASH_API_TOKEN,
},
});
if (unleash.isEnabled('new-checkout-flow', { userId: user.id })) {
return newCheckoutHandler(req, res);
}
return legacyCheckoutHandler(req, res);
SDK кешує стан прапорців та синхронізується з сервером. Якщо Unleash недоступний — SDK працює з останнім відомим станом. Падіння сервера не кладе ваш сервіс, забезпечуючи 99.9% uptime.
Кейс впровадження (наш досвід)
З нашої практики: у нашого клієнта з фінтеху було 5 мікросервісів, кожен з окремими змінними середовища. Після впровадження самописного сервера на базі Unleash час релізу скоротився з 1 дня до 2 годин (у 12 разів швидше), а кількість відкатів знизилася на 80%. Це стало можливим завдяки gradual rollout та миттєвим відкатам через UI.
Порівняння: env variables vs Feature Toggle сервер
| Характеристика | Змінні середовища | Feature Toggle сервер |
|---|---|---|
| Час ввімкнення фічі | 15–30 хвилин (деплой) | 0 секунд (UI/API) — у сотні разів швидше |
| Audit log | Немає | Є, з timestamp |
| Gradual rollout | Неможливий | Доступний |
| A/B тестування | Немає | Так |
| Ризик відкату | Повний редеплой | Одне натискання в UI |
Як правильно використовувати gradual rollout?
Gradual rollout — основна функція. Вмикаєте фічу для 10% користувачів, дивитеся метрики (latency, errors, conversion), розширюєте до 20%, 100%. В Unleash це activation strategy gradualRollout з параметрами: Rollout percentage та Stickiness по userId. Stickiness гарантує, що користувач бачить однаковий стан при кожному запиті. Без неї — поганий UX. Як зазначено в офіційній документації Unleash, це критично для консистентності. Gradual rollout в 10 разів ефективніший за ручне тестування — вимірюєте реальні метрики, а не гадаєте.
Порівняння Unleash vs Flagsmith
| Характеристика | Unleash | Flagsmith |
|---|---|---|
| Зрілість | 5+ років, великі компанії | 3+ роки, активний розвиток |
| Activation strategies | gradual rollout, IP, custom segment | відсоткове ввімкнення, сегменти |
| Remote config | Немає (тільки boolean) | Так (string, number, JSON) |
| UI | Функціональний, але застарілий | Сучасний, інтуїтивний |
| GitLab інтеграція | Нативна | Через API |
| Latency API | У середньому на 30% швидше | Повільніше на 30% |
Якщо потрібні лише прапорці та використовуєте GitLab — обирайте Unleash. Якщо потрібні remote config — Flagsmith.
Які проблеми вирішує Feature Toggle сервер?
Feature toggle сервер вирішує три ключові проблеми: залежність деплою від релізу, відсутність аудиту змін та неможливість A/B тестування. Також дозволяє робити відкат миттєво — вимкнути прапорець в UI за секунду.
Процес роботи
- Аналітика: визначаємо, які прапорці потрібні, оцінюємо обсяг інтеграції.
- Проектування: обираємо систему (Unleash/Flagsmith), проектуємо інфраструктуру (K8s, PostgreSQL, метрики).
- Реалізація: розгортання сервера, налаштування БД, інтеграція SDK у ваші сервіси (один-два для прикладу).
- Тестування: функціональне тестування прапорців, навантажувальне тестування сервера.
- Деплой: production-ready розгортання з моніторингом та бекапами.
Що входить в роботу
- Розгортання self-hosted сервера (Unleash/Flagsmith) у вашому кластері K8s.
- Налаштування PostgreSQL (managed RDS/Cloud SQL).
- Інтеграція SDK в 2 ключові сервіси на прикладі.
- Навчання команди: lifecycle прапорця, робота з UI, моніторинг.
- Документування архітектури та процесів.
- Гарантія стабільної роботи 24/7, підтримка 30 днів після впровадження.
Резервне копіювання
Налаштовуємо щогодинні бекапи PostgreSQL в S3-сумісне сховище та повний дамп раз на добу. Відновлення з бекапу займає не більше 15 хвилин. Додатково — моніторинг стану бекапів через Prometheus алерти.
Досвід та результати
Ми маємо 5+ років досвіду впровадження feature toggles та 20+ успішних проєктів. Типовий час впровадження — 3 дні. Зниження MTTR на 60% за рахунок миттєвих відкатів. Впевнені, що feature flags прискорять ваші релізи. Замовте консультацію — підберемо оптимальну систему та оцінимо обсяг робіт.
Терміни та вартість
Впровадження коштує від $2000 до $5000 залежно від складності. Термін — від 2 до 5 днів. Оцінимо ваш проєкт — зв'яжіться для консультації. Отримайте консультацію з впровадження — прискорте свої релізи.
