Nasazení je, když kód dorazí do výroby. Vydání je, když to někdo může skutečně použít. Záměna těchto dvou je jedním z nejrychlejších způsobů, jak z každého nasazení udělat trochu napjatý moment.
feature flag slouží k vložení mezery mezi tyto dva momenty. Můžete nasadit dnes, zítra spustit pro interní tým, pak pro pilotního zákazníka a poté pro 10 % uživatelů. Pokud se něco pokazí, vypněte vlajku. Nemusíte nutně vrátit zpět celé vydání.
Vlajka není jen kdyby
Technicky je to často if. Kulturně je to mnohem víc.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Tato malá if může představovat postupné zavádění, experiment, migraci, podnikové povolení nebo provozní kill switch. Problém je v tom, že pokud to špatně spravujete, může se z toho stát i technický dluh, který zůstane v kódu dva roky.
Kde se bere OpenFeature
OpenFeature je otevřená specifikace pro hodnocení feature flag se společným API. Myšlenka je jednoduchá: kód vaší aplikace by neměl přímo záviset na dodavateli nebo interním systému, který používáte pro příznaky.
Aplikace se ptá:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
Poskytovatel rozhodne, odkud pravidla pocházejí: SaaS, soubor, interní služba, příznak, konfigurace GitOps. Pokud jednoho dne změníte backend označující funkce, aplikace se nemusí všude přepisovat.
Toto oddělení vypadá jako architektonický detail, ale je cítit, jak projekt roste.
Kontext je polovina úspěchu
Příznak zapnutí nebo vypnutí pro každého je užitečný, ale omezený. Progresivní doručování žije v kontextu:
- interní nebo externí uživatel;
- bezplatný nebo podnikový plán;
- vesnice;
- organizace;
- verze aplikace;
- stabilní procento provozu.
Důležitý klíč je targetingKey: musí být stabilní. Pokud se mění s každým požadavkem, může uživatel skončit jednou ve variantě A a jednou ve variantě B. Pro experiment je to hrozné, pro pokladnu to může být katastrofální.
Rozumné zavedení
Tok, který se mi líbí, je tento:
- nasadit s vypnutým praporkem;
- zapalování pro vývojáře a QA;
- zapnutí pro pilotního zákazníka nebo nájemce;
- 5% zavedení;
- zavedení na 25 %;
- 100% zavedení;
- odstranění starého kódu a vlajky.
Často zapomínaný bod je ten poslední. Dočasná vlajka musí mít datum smrti. Pokud to zůstane navždy, každý budoucí refaktor se bude muset zeptat: "ale je tato větev stále užitečná?".
Kill switch: nejprve je připravte
kill switch je příznak, který vás zachrání, když si s vámi začne hrát externí závislost, úloha spotřebovává příliš mnoho zdrojů nebo nová logika vytváří podivné chyby.
Dobrý kill switch musí být:
- snadné najít;
- dokumentováno v runbooku;
- občas testováno;
- pozorovatelné při aktivaci;
- nezávislé, pokud možno, na části, která by se mohla zlomit.
Nejhorší je při nehodě zjistit, že vlajka existuje, ale nikdo neví, jestli ještě funguje.
Pozorovatelnost nebo neprogresivní doručení
Zapnutí funkce na 10 % bez pohledu na metriky je jen optimismus s více kroky.
Každé vydání by mělo odpovědět na jednoduché otázky:
- přibylo chyb?
- změnila se latence?
- dokončí uživatelé tok?
- je více lístků nebo opakování?
- ovlivňuje varianta pouze jeden segment?
OpenFeature podporuje háčky kolem vyhodnocování příznaků. Jsou užitečné pro protokolování chyb, přidávání metrik nebo propojení hodnocení s trace.
Pojmenování a vlastnictví
Na jménech záleží. new_ui neříká nic. checkout.v2.enabled říká mnohem víc.
Pro každou vlajku bych označil alespoň:
- jméno;
- popis;
- vlastník;
- bezpečné výchozí nastavení;
- důvod, proč existuje;
- datum nebo podmínka odstranění.
Vlajka bez vlastníka je téměř vždy vlajkou, kterou nikdo nevymaže.
Kde je hodnotit
Frontend, backend nebo edge? Závisí.
Pokud je příznak pro rozvržení, kopírování nebo začlenění, frontend je v pořádku. Pokud jde o oprávnění, fakturaci, limity nebo citlivá data, musí být na backendu. Pokud to zahrnuje směrování nebo experimenty s vysokým provozem, může mít okraj smysl.
Jednoduché pravidlo: frontend může zlepšit zážitek, ale neměl by být jedinou bezpečnostní bariérou.
Závěr
Dobře provedené feature flag mění vztah k produkci. Neeliminují riziko, ale dělají ho menší a lépe zvládnutelný. Můžete se uvolnit v řezech, pozorovat, zastavit se, vrátit se, učit se.
OpenFeature přidává čistý základ: společný API, zaměnitelné poskytovatele a přehlednější způsob, jak systém rozvíjet. Ale disciplína zůstává na vás: bezpečné výchozí hodnoty, jasná jména, metriky, vlastníci a čistota.
Nejlepší vlajka je ta, která vám pomůže se klidně uvolnit a pak zmizí, když už není potřeba.