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.