Feature flags i et lille team — uden platform-teater

Udrulning uden nedetid er ikke et load-balancer-trick. Det er at I kan sende kode, der er mørk for de fleste, og tænde den når I tør — eller slukke den når den brænder. Uden den ventil merger I om natten, hotfix'er i panik, eller lader en feature rådne på en branch, fordi 'vi ikke kan rulle delvist ud'.

Små teams køber den forkerte medicin. De ser et slide med procentuel udrulning, multivariate tests og 'governance', og tegner et platform-projekt oven på et checkout, der bare skulle kunne slås fra. Eller de gør det modsatte: de har ingen ventil, så hver release er et spring. Begge dele koster uger. Den ene i teater. Den anden i rollback.

Det er også et produktspørgsmål, ikke kun et DevOps-spørgsmål. Et flag, der lever i et år, er en skjult indstilling. To sandheder i koden. To veje i QA. To måder en kunde kan ramme en fejl på. Preview-deploys fanger det, I kan se før merge. De fanger ikke det flag, I glemte at slette efter go-live.

Vi skriver det, fordi 'feature flags' er blevet et køb, I tager før I har en sætning om hvad der slås til. Et ærligt setup er kedeligt: en boolean, et sted I kan læse den i requesten, en person der ejer den, og en dato hvor koden kun har én vej. Uden den sætning har I et dashboard. I har ikke udrulning, I kan forsvare.

Et feature flag er en værdi, runtime læser, mens requesten kører. Koden er allerede ude. Beslutningen er ikke. Det er forskellen på at deploye og at slå til. Hvis I skal bygge image om, røre Vercel-env og vente på en ny deploy, har I en konfiguration. Den kan være rigtig — en kill-switch I sjældent rører. Den er ikke et flag I kan bruge midt i en hændelse.

Derfor er NEXT_PUBLIC_ENABLE_BILLING=true næsten altid en løgn, når nogen siger flag. NEXT_PUBLIC_ lander i browser-bundlen. Klienten har allerede svaret, før jeres 'off' findes. En middleware, der læser en server-hemmelighed eller en række i jeres database, kan stadig sige nej. Et client-bundle kan ikke tage et nej tilbage, I sendte med for to deploys siden.

Et flag er heller ikke et settings-produkt. 'Hver lejer kan selv slå mørkt tema, nyt dashboard og beta-faktura til' er feature-toggle som forretning. Det kræver UI, audit, support. Det er fint, når det er produktet. Det er gift, når I startede med 'bare så vi kan rulle stille ud' og endte med et internt kontrolpanel, ingen tør røre.

Og det er ikke en erstatning for preview. En PR uden URL er stadig et review i blindo. Flaget hjælper jer ikke med at se layoutet før merge. Det hjælper jer med at have koden ude, uden at alle kunder står på den nye sti. Hvis I kun har det ene, har I kun halvdelen af udrulningen.

Den første fejl er at købe platformen, før I har én boolean, I faktisk slår til og fra. I får SDK, audit-log og 'environments', og så bruger I ét flag til checkout. Tre måneder senere er SDK'et den eneste grund til at flaget stadig findes, og ingen husker API-nøglen. I betaler for governance, I ikke læser.

Den anden fejl er env-var som teater. I skifter en værdi, trigger et redeploy, og kalder det 'udrulning uden nedetid'. Det er en langsom kill-switch. Den er bedre end ingenting, hvis I kun har én knap, I rører ved en hændelse. Den er ubrugelig, hvis I vil tænde for én lejer i eftermiddag uden at bygge om.

Den tredje fejl er targeting som første feature. 'Ti procent af sessionerne, undtagen staff, plus det her workspace'. Nu har I et regelsprog. Nu kan to flags interagere. Nu kan en kunde se A på desktop og B på telefonen, fordi cookien ikke fulgte med. Targeting er rigtigt, når I har et spørgsmål targeting svarer på. Det er forkert som standard på et MVP.

Den fjerde fejl er at lade flaget blive den måde, I gemmer uenigheder. Produkt vil have det ude. Support vil ikke. I merger og lader flaget stå på off. Et halvt år senere tør ingen slette koden, fordi 'den måske skal bruges'. Det er ikke udrulning. Det er en uenighed, I har skubbet ind i runtime.

App Router gør det nemt at tro, at 'det kører på serveren'. En Server Component kan læse et flag rigtigt. En Client Component, der får flaget som en prop I cached for aggressivt, eller som selv henter et NEXT_PUBLIC_, kan vise den forkerte verden i minutter. Cache er en del af flaget. Hvis I ikke kan sige, hvor længe et 'off' må være forkert, har I ikke en kill-switch. I har et håb.

Middleware er et ærligt sted at gate'e en hel sti — /ny-kasse kun når flaget er på. Det er også et sted, I kan gøre requesten langsom, eller cache'e beslutningen så hårdt, at sluk ikke slår igennem. Hold flag-læsningen kort. Hold den tæt på det, I faktisk vil skjule. Gate ikke hele sitet fordi én flow skal kunne slukkes.

Vercel Flags, edge config og de sædvanlige SaaS-SDK'er kan være rigtige, når I har flere miljøer, flere teams og et behov for at slå til uden et deploy. De er forkerte som første commit på et MVP, hvor én person kan opdatere en række og refreshe. Køb pipen, når læsningen er blevet et produkt. Køb den ikke, fordi et blogindlæg sagde, at feature flags er 'moderne'.

Hvis I overvejer at skifte host eller framework 'for at få flags', så vær ærlige: I skifter sted, beslutningen kan sidde. Et Next.js-site med det samme env-teater er ikke en ny ventil. Skift stak hvis I også har andre grunde. Skift ikke fordi et slide sagde, at edge gør udrulning usynlig. Udrulning er hvem der ser koden. Ikke hvor den compiles.