Розгортання – це коли код надходить у виробництво. Звільнення – це коли хтось дійсно може цим скористатися. Сплутати ці два – один із найшвидших способів зробити кожне розгортання трохи напруженим моментом.
feature flag служить для розміщення проміжку між цими двома моментами. Ви можете розгорнути сьогодні, завтра розпочати роботу для внутрішньої команди, потім для пілотного клієнта, потім для 10% користувачів. Якщо щось піде не так, вимкніть прапор. Вам не обов’язково відкочувати весь випуск.
Прапор - це не просто якщо
Технічно це часто if. Культурно це набагато більше.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Цей маленький if може означати поступове розгортання, експеримент, міграцію, дозвіл підприємства або операційну kill switch. Проблема полягає в тому, що якщо ви не керуєте ним належним чином, це також може стати технічним боргом, який залишається в коді протягом двох років.
Де тут OpenFeature
OpenFeature є відкритою специфікацією для оцінки feature flag із загальним API. Ідея проста: ваш код програми не повинен залежати безпосередньо від постачальника або внутрішньої системи, яку ви використовуєте для прапорів.
Додаток запитує:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
Постачальник вирішує, звідки беруться правила: SaaS, файл, внутрішня служба, flagd, конфігурація GitOps. Якщо одного дня ви зміните бекенд позначення функцій, програму не доведеться переписувати всюди.
Це поділ здається архітектурною деталлю, але це відчувається в міру того, як проект росте.
Контекст — половина успіху
Прапор увімкнення чи вимкнення для всіх корисний, але обмежений. Прогресивне постачання живе в контексті:
- внутрішній або зовнішній користувач;
- вільний або корпоративний план;
- село;
- організованість;
- версія програми;
- стабільний відсоток трафіку.
Важлива клавіша targetingKey: вона має бути стабільною. Якщо він змінюється з кожним запитом, користувач може опинитися один раз у варіанті А і один раз у варіанті Б. Для експерименту це жахливо, для перевірки це може бути катастрофічним.
Розумне впровадження
Потік, який мені подобається, такий:
- розгорнути зі знятим прапором;
- запалювання для розробників і QA;
- включення для пілотного замовника або орендаря;
- 5% розгортання;
- розгортання на 25%;
- 100% розгортання;
- видалення старого коду та прапора.
Останній пункт, про який часто забувають. Тимчасовий прапор повинен мати дату смерті. Якщо це залишиться назавжди, кожному майбутньому рефактору доведеться запитати: «а чи ця гілка все ще корисна?».
Kill switch: спочатку приготуйте їх
kill switch — це прапорець, який рятує вас, коли зовнішня залежність починає заважати вам, робота споживає забагато ресурсів або нова логіка породжує дивні помилки.
Хороший kill switch має бути:
- легко знайти;
- задокументовано в журналі операцій;
- тестується час від часу;
- спостерігаються при активації;
- незалежно, наскільки це можливо, від частини, яка може зламатися.
Найгірше під час аварії виявити, що прапор є, але ніхто не знає, чи він досі працює.
Спостережуваність чи не прогресивна доставка
Увімкнути функцію на 10%, не дивлячись на показники, — це лише оптимізм із кількома кроками.
Кожен випуск має відповідати на прості запитання:
- чи побільшало помилок?
- чи змінилася затримка?
- чи завершують користувачі потік?
- є ще квитки чи повторні спроби?
- чи впливає варіант лише на один сегмент?
OpenFeature підтримує хуки навколо оцінки прапора. Вони корисні для реєстрації помилок, додавання показників або зв’язування рейтингу з trace.
Назва та право власності
Імена мають значення. new_ui нічого не говорить. checkout.v2.enabled говорить набагато більше.
Для кожного прапора я б позначив принаймні:
- ім'я;
- опис;
- власник;
- безпечний дефолт;
- причина його існування;
- дата або умова вилучення.
Безхазяйний прапор – це майже завжди прапор, який ніхто не зніме.
Де їх оцінити
Frontend, backend чи edge? Залежить.
Якщо прапорець для макета, копіювання або адаптації, інтерфейс підійде. Якщо це стосується дозволів, виставлення рахунків, лімітів або конфіденційних даних, це має бути на сервері. Якщо це стосується маршрутизації або експериментів із високим трафіком, перевага може мати сенс.
Просте правило: інтерфейс може покращити досвід, але він не повинен бути єдиним бар’єром безпеки.
Висновок
feature flag зроблено добре змінює відносини з виробництвом. Вони не усувають ризик, але роблять його меншим і більш керованим. Ви можете випускати фрагменти, спостерігати, зупинятися, повертатися назад, вчитися.
OpenFeature додає чисту основу: загальний API, взаємозамінних постачальників і більш охайний спосіб розвитку системи. Але дисципліна залишається за вами: безпечні параметри за замовчуванням, чіткі імена, показники, власники та чистота.
Найкращий прапор – це той, який допомагає спокійно звільнитися, а потім зникає, коли він більше не потрібен.