Feature flag: släpp utan att hålla andan

Implementering är när koden kommer i produktion. Release är när någon faktiskt kan använda den. Att blanda ihop de två är ett av de snabbaste sätten att göra varje distribution till ett lite spänt ögonblick.

feature flag tjänar till att sätta utrymme mellan dessa två ögonblick. Du kan distribuera idag, starta imorgon för det interna teamet, sedan för en pilotkund och sedan för 10 % av användarna. Om något går fel, stäng av flaggan. Du behöver inte nödvändigtvis återställa hela versionen.

Flaggan är inte bara ett om

Tekniskt sett är det ofta en if. Kulturellt är det mycket mer.

if (await flags.isEnabled('checkout.v2.enabled', context)) {
  return newCheckout(input);
}

return oldCheckout(input);

Den lilla if kan representera en gradvis utbyggnad, ett experiment, en migration, ett företagstillstånd eller en operativ kill switch. Problemet är att om man inte sköter det bra kan det också bli tekniska skulder som stannar i koden i två år.

Var kommer OpenFeature in

OpenFeature är en öppen specifikation för att utvärdera feature flag med en gemensam API. Tanken är enkel: din applikationskod bör inte bero direkt på leverantören eller det interna systemet du använder för flaggor.

Appen frågar:

const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {
  targetingKey: user.id,
  plan: user.plan,
  country: user.country,
});

Leverantören bestämmer var reglerna kommer ifrån: SaaS, fil, intern tjänst, flagd, GitOps-konfiguration. Om du en dag byter funktionsflaggande backend behöver applikationen inte skrivas om överallt.

Denna separation verkar vara en arkitektonisk detalj, men det känns när projektet växer.

Sammanhang är halva striden

En på eller av-flagga för alla är användbar, men begränsad. Progressiva leveranslivslängder i sammanhang:

intern eller extern användare;
gratis eller företagsplan;
by;
organisation;
appversion;
stabil andel av trafiken.

Den viktiga nyckeln är targetingKey: den måste vara stabil. Om det ändras med varje begäran kan en användare hamna en gång i variant A och en gång i variant B. För ett experiment är det fruktansvärt, för en kassa kan det vara katastrofalt.

En vettig utbyggnad

Ett flöde jag gillar är detta:

distribuera med flaggan avstängd;
tändning för utvecklare och QA;
påslagning för en pilotkund eller hyresgäst;
5 % utbyggnad;
utbyggnad vid 25 %;
100 % utrullning;
borttagning av gammal kod och flagga.

Den ofta bortglömda punkten är den sista. En tillfällig flagga måste ha ett dödsdatum. Om den stannar för alltid kommer varje framtida refactor att behöva fråga: "men är den här grenen fortfarande användbar?".

Kill switch: förbered dem först

kill switch är flaggan som räddar dig när ett externt beroende börjar bråka med dig, ett jobb förbrukar för mycket resurser eller ny logik ger konstiga fel.

En bra kill switch måste vara:

lätt att hitta;
dokumenterad i runbook;
testas ibland;
observerbar när den är aktiverad;
oberoende, så långt det är möjligt, från den del som kan gå sönder.

Det värsta är att under olyckan upptäcka att flaggan finns, men ingen vet om den fortfarande fungerar.

Observerbarhet eller inte progressiv leverans

Att aktivera en funktion på 10 % utan att titta på mätvärden är bara optimism med flera steg.

Varje utrullning ska svara på enkla frågor:

har felen ökat?
har latensen förändrats?
slutför användare flödet?
finns det fler biljetter eller omförsök?
påverkar en variant bara ett segment?

OpenFeature stöder krokar kring flaggutvärdering. De är användbara för att logga fel, lägga till mätvärden eller länka betyget till en trace.

Namngivning och ägande

Namn spelar roll. new_ui säger ingenting. checkout.v2.enabled säger mycket mer.

För varje flagga skulle jag markera minst:

namn;
beskrivning;
ägare;
säker standard;
anledningen till att den existerar;
datum eller skick för avlägsnande.

En ägarelös flagga är nästan alltid en flagga som ingen kommer att rensa.

Var man ska utvärdera dem

Frontend, backend eller kant? Beror på.

Om flaggan är för layout, kopiering eller onboarding är frontend bra. Om det gäller behörigheter, fakturering, gränser eller känsliga uppgifter måste det finnas på backend. Om det involverar routing eller experiment med hög trafik kan kanten vara vettig.

Den enkla regeln: frontend kan förbättra upplevelsen, men det borde inte vara den enda säkerhetsbarriären.

Slutsats

De feature flag bra gjort förändrar förhållandet till produktionen. De eliminerar inte risken, men de gör den mindre och mer hanterbar. Du kan släppa i skivor, observera, stanna, gå tillbaka, lära dig.

OpenFeature lägger till en ren grund: en gemensam API, utbytbara leverantörer och ett snyggare sätt att växa systemet. Men disciplinen förblir din: säkra standardinställningar, tydliga namn, mätvärden, ägare och renlighet.

Den bästa flaggan är den som hjälper dig att släppa lugnt och sedan försvinner när den inte längre behövs.

Källor