Implementering er, når koden ankommer i produktion. Frigivelse er, når nogen rent faktisk kan bruge det. At forveksle de to er en af de hurtigste måder at gøre hver implementering til et lidt anspændt øjeblik.
feature flag tjener til at sætte plads mellem disse to øjeblikke. Du kan implementere i dag, starte i morgen for det interne team, derefter for en pilotkunde og derefter for 10 % af brugerne. Hvis noget går galt, skal du slukke for flaget. Du behøver ikke nødvendigvis at rulle hele udgivelsen tilbage.
Flaget er ikke bare et hvis
Teknisk set er det ofte en if. Kulturelt er det meget mere.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Den lille if kan repræsentere en gradvis udrulning, et eksperiment, en migration, en virksomhedstilladelse eller en operationel kill switch. Problemet er, at hvis man ikke klarer det godt, kan det også blive teknisk gæld, der bliver i koden i to år.
Hvor kommer OpenFeature ind
OpenFeature er en åben specifikation til evaluering af feature flag med en fælles API. Ideen er enkel: din applikationskode bør ikke afhænge direkte af den leverandør eller det interne system, du bruger til flag.
Appen spørger:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
Udbyderen bestemmer, hvor reglerne kommer fra: SaaS, fil, intern service, flagd, GitOps-konfiguration. Hvis du en dag ændrer funktionsflaggende backend, behøver applikationen ikke at blive omskrevet overalt.
Denne adskillelse virker som en arkitektonisk detalje, men den mærkes efterhånden som projektet vokser.
Kontekst er halvdelen af kampen
Et tændt eller slukket flag for alle er nyttigt, men begrænset. Progressive leveringstider i sammenhæng:
- intern eller ekstern bruger;
- gratis eller virksomhedsplan;
- landsby;
- organisation;
- app version;
- stabil procentdel af trafikken.
Den vigtige nøgle er targetingKey: den skal være stabil. Hvis det ændrer sig med hver anmodning, kan en bruger ende én gang i variant A og én gang i variant B. For et eksperiment er det forfærdeligt, for en checkout kan det være katastrofalt.
En fornuftig udrulning
Et flow jeg kan lide er dette:
- deploy med flag off;
- tænding for udviklere og QA;
- tænding for pilotkunde eller lejer;
- 5% udrulning;
- udrulning ved 25%;
- 100% udrulning;
- fjernelse af gammel kode og flag.
Det ofte glemte punkt er det sidste. Et midlertidigt flag skal have en dødsdato. Hvis det forbliver for evigt, bliver enhver fremtidig refactor nødt til at spørge: "men er denne gren stadig nyttig?".
Kill switch: forberede dem først
kill switch er flaget, der redder dig, når en ekstern afhængighed begynder at rode med dig, et job bruger for mange ressourcer, eller ny logik producerer mærkelige fejl.
En god kill switch skal være:
- let at finde;
- dokumenteret i runbook;
- testet lejlighedsvis;
- observerbar, når den er aktiveret;
- så vidt muligt uafhængig af den del, der kunne gå i stykker.
Det værste er under ulykken at opdage, at flaget eksisterer, men ingen ved, om det stadig virker.
Observerbarhed eller ikke progressiv levering
At slå en funktion til på 10 % uden at se på metrics er blot optimisme med flere trin.
Hver udrulning skal besvare simple spørgsmål:
- er antallet af fejl steget?
- har latensen ændret sig?
- fuldfører brugerne flowet?
- er der flere billetter eller genforsøg?
- påvirker en variant kun ét segment?
OpenFeature understøtter kroge omkring flagevaluering. De er nyttige til at logge fejl, tilføje metrics eller knytte vurderingen til en trace.
Navngivning og ejerskab
Navne betyder noget. new_ui siger ingenting. checkout.v2.enabled siger meget mere.
For hvert flag vil jeg som minimum markere:
- navn;
- beskrivelse;
- ejer;
- sikker standard;
- grunden til, at den eksisterer;
- dato eller tilstand for fjernelse.
Et ejerløst flag er næsten altid et flag, som ingen vil klare.
Hvor skal man evaluere dem
Frontend, backend eller kant? Afhænger.
Hvis flaget er til layout, kopiering eller onboarding, er frontenden fint. Hvis det drejer sig om tilladelser, fakturering, grænser eller følsomme data, skal det være på backend. Hvis det involverer routing eller eksperimenter med høj trafik, kan kanten give mening.
Den simple regel: Frontend kan forbedre oplevelsen, men det burde ikke være den eneste sikkerhedsbarriere.
Konklusion
De feature flag, der er gjort godt, ændrer forholdet til produktionen. De eliminerer ikke risikoen, men de gør den mindre og mere overskuelig. Du kan slippe i skiver, observere, stoppe, gå tilbage, lære.
OpenFeature tilføjer et rent fundament: en fælles API, udskiftelige udbydere og en mere ryddelig måde at udvikle systemet på. Men disciplinen forbliver din: sikre standarder, klare navne, målinger, ejere og renlighed.
Det bedste flag er det, der hjælper dig med at slippe roligt og så forsvinder, når det ikke længere er nødvendigt.