Feature flags og nødstop: slå én risikabel funktion fra uden nyt deploy

Hvad løser et feature flag?

Deployment og frigivelse er ikke altid det samme. Koden kan være deployet i produktion, mens den nye funktion stadig er skjult for almindelige brugere. Microsoft beskriver feature management som netop adskillelsen mellem kode-deployment og frigivelse af en funktion. OpenFeature beskriver samme grundidé som en beslutning, der ændrer appens adfærd ved kørsel.

Et flag er ikke nødvendigt for enhver tekstændring eller almindelig fejlrettelse. Det er mest nyttigt, når en funktion har en reel driftsrisiko, kan adskilles tydeligt fra resten af appen og har en sikker adfærd, når den er slået fra.

Vælg den sikre adfærd før værktøjet

OpenFeature kræver, at kode, der evaluerer et flag, angiver en standardværdi, som bruges ved blandt andet fejl. Derfor skal teamet beslutte, hvad appen gør, hvis flagtjenesten er langsom, utilgængelig eller returnerer en ukendt værdi. “Fra” er ofte sikkert, men ikke altid: Et flag foran adgangskontrol, datavalidering eller en anden beskyttelse må aldrig åbne sikkerheden ved fejl.

Beskriv også, om et skift skal påvirke igangværende arbejde. At lukke knappen i frontend stopper ikke nødvendigvis et job, der allerede kører på serveren. Nødstop skal derfor placeres ved den handling, der faktisk skaber virkningen.

Et flag er ikke en rettighed

Et klientflag kan ofte ses eller manipuleres af brugeren. Firebase advarer direkte mod fortrolige værdier i Remote Config og mod at bruge tjenesten til ændringer, som kræver brugerautorisation. OWASP anbefaler, at adgang som udgangspunkt afvises og kontrolleres på hver request. Derfor må en skjult knap eller et klientflag aldrig være det eneste, der beskytter data eller en privilegeret handling.

• Bevar autorisationen server-side. Rollen, virksomheden og retten til den konkrete datapost skal stadig kontrolleres, selv om flaget er åbent.
• Gem ingen secrets i flaget. API-nøgler, tokens og skjulte endpoints hører til i appens normale secret-opbevaring.
• Evaluér den kritiske virkning på serveren. Frontend må gerne skjule en knap, men API'et skal også afvise eller vælge den sikre vej.
• Begræns hvem der kan ændre flags. Brug mindst mulige rettigheder, stærkt login og en historik over ændringer.

Lav en lille kontrakt for hvert flag

Et navn som newFlowfortæller for lidt under en hændelse. Skriv en kort kontrakt, så en anden kan forstå konsekvensen uden at læse hele kodebasen.

Formål og sikker standard

Hvilken risiko afgrænses, og hvad sker der ved “fra”, ukendt værdi eller tjenestefejl?

Ejer og adgang

Hvem må ændre flaget, hvem godkender bredere udrulning, og hvem reagerer på en alarm?

Mål og stopkriterier

Hvilke fejl, svartider, omkostninger eller forretningsafvigelser udløser pause eller nødstop?

Sluttilstand og oprydningsdato

Hvornår bliver funktionen permanent, fjernet eller erstattet, så gamle kodeveje ikke lever for evigt?

Udrul efter risiko og mål den faktiske virkning

En procentregel er ikke i sig selv en sikker udrulning. Den samme bruger eller virksomhed bør normalt få en stabil oplevelse gennem hele forløbet, og en kritisk arbejdsgang bør måles fra handling til resultat. OpenFeature beskriver en stabil targeting key til deterministisk procentvis evaluering; Firebase og Azure tilbyder målgrupper og gradvis udrulning i deres egne værktøjer.

1. Afprøv “fra” og fejltilstand. Bekræft, at appen starter og handler sikkert, når flagtjenesten ikke svarer.
2. Åbn for en kendt testgruppe. Brug interne konti eller en aftalt pilotkunde – ikke rigtige brugeres emailadresser som synlige flagdata.
3. Udvid i kontrollerede trin. Vælg grupper eller andele efter appens brugsmønster frem for en fast opskrift.
4. Mål både teknik og forretning. Se på fejl, svartid og forbrug samt eksempelvis gennemførte betalinger, korrekte imports eller leverede beskeder.
5. Stop ved aftalte signaler. Slå funktionen fra, stabilisér igangværende arbejde og afstem data, før udrulningen fortsætter.

Registrér gerne flagets nøgle og variant i relevante, dataminimerede driftslogs. Så kan fejl sammenholdes med den kodevej, der faktisk var aktiv, uden at logge hele målgruppeprofilen eller følsomme flagværdier.

Vælg implementering efter appens stack

Det vigtige er den sikre adfærd og driftsprocessen – ikke et bestemt produkt. Firebase-apps kan bruge Remote Config. Azure-løsninger kan bruge App Configuration. OpenFeature tilbyder et leverandøruafhængigt API, der forbindes til en kompatibel flagudbyder. En lille app kan også bruge en beskyttet database- eller konfigurationsværdi, hvis cache, adgang, historik og fejltilstand er gennemtænkt.

• Hold test- og produktionsflags adskilt, så en test ikke ændrer rigtige brugeres oplevelse.
• Brug en lokal, sikker standard, hvis den eksterne konfiguration ikke kan hentes.
• Kontrollér hvor hurtigt ændringer slår igennem; caching kan gøre et “øjeblikkeligt” nødstop forsinket.
• Log ændringer med aktør, tidspunkt og begrundelse, og beskyt administrationsvejen som en driftsfunktion.
• Test både den aktive og inaktive kodevej, så den sjældent brugte fallback ikke rådner.

Øv nødstop, mens situationen er rolig

Et flag giver kun ro, hvis nogen kan finde det, ændre det og kontrollere virkningen. Lav en kort øvelse i et sikkert miljø og derefter en kontrolleret produktionsøvelse på en ufarlig funktion eller aftalt testgruppe.

Typiske fejl

• Kun knappen skjules: API'et kan stadig kaldes direkte og udføre handlingen.
• Flaget åbner ved fejl: En utilgængelig flagtjeneste aktiverer den risikable kodevej.
• Secret ligger i konfigurationen: Klienter kan læse en værdi, som blev behandlet som hemmelig.
• Ingen stabil målretning: Brugeren skifter tilfældigt mellem to forløb og efterlader inkonsistente data.
• Nødstop ignorerer igangværende arbejde: Nye handlinger stoppes, mens gamle jobs fortsætter usynligt.
• Ingen målinger: Udrulningen øges, selv om fejl, svartid eller forretningsresultat er forværret.
• Flaget bliver permanent: Begge kodeveje og gamle regler lever videre uden ejer eller test.

Tjekliste før et feature flag bruges i produktion

• ☐ Flagets formål, risikable funktion og sikre “fra”-adfærd er beskrevet.
• ☐ Appen har en bevidst standardværdi ved timeout, fejl eller ukendt konfiguration.
• ☐ Autorisation, validering og andre sikkerhedskontroller virker uafhængigt af flaget.
• ☐ Secrets og fortrolige målgruppedata ligger ikke i klientens flagkonfiguration.
• ☐ Den kritiske virkning kontrolleres server-side, ikke kun i brugergrænsefladen.
• ☐ Test- og produktionsflags, adgang og data er adskilt.
• ☐ En ejer, godkender og alarmmodtager er navngivet.
• ☐ Målgruppe eller procentvalg er stabilt for samme bruger eller virksomhed.
• ☐ Fejl, svartid, omkostning og relevant forretningsresultat kan sammenlignes pr. variant.
• ☐ Stopkriterier og håndtering af igangværende arbejde er aftalt.
• ☐ Ændringer logges med aktør, tidspunkt og begrundelse.
• ☐ Både aktiv, inaktiv og fejlende flagtjeneste er afprøvet.
• ☐ Nødstop er øvet, og virkningen er kontrolleret i app, API og jobs.
• ☐ Flaget har en dato og beslutning for fjernelse eller permanentgørelse.

Officielle kilder

Funktioner, cache, målretning og opdateringshastighed varierer mellem udbydere og SDK'er. Kontrollér dokumentationen til den konkrete stack og version, før flaget får lov at styre en vigtig produktionshandling.

• OpenFeature: introduktion til feature flags og runtime-styring
• OpenFeature: standardværdi og fejl ved evaluering af flags
• OpenFeature: stabil targeting key og dataminimering i målretning
• Microsoft: feature management med switch, rollout og eksperiment
• Firebase: Remote Config, udrulning og sikkerhedsbegrænsninger
• OWASP: autorisation skal håndhæves som deny-by-default på hver request