Hvad er feature flags?
Et feature flag er en afbryder i koden der slår en funktion til eller fra uden en ny release. Det bruges til gradvis udrulning, til at teste med udvalgte kunder og som panikknap hvis noget går galt. Flaget adskiller idriftsættelse fra lancering, men ubrugte flag bliver til teknisk gæld hvis der aldrig bliver ryddet op i dem.
Feature flags er et af de greb der adskiller et modent udviklingsteam fra et der udgiver nye funktioner med krydsede fingre. Begrebet lyder teknisk, men idéen er hverdagsagtig: en afbryder. Her er hvad et feature flag er, hvad det bruges til, og hvorfor det er værd at kende til, også som kunde.
Definitionen
Et feature flag, nogle gange kaldet en feature toggle, er en afbryder bygget ind i koden som slår en funktion til eller fra uden at der skal udgives en ny version. Funktionen er på plads i softwaren, men flaget afgør om den er synlig og aktiv eller ej.
Det lyder enkelt, og det er det. Men effekten er stor: Det bryder koblingen mellem at koden findes, og at funktionen er tændt. I stedet for at en ny funktion uundgåeligt går live i samme sekund som den bliver udgivet, kan teamet bestemme præcis hvornår, for hvem og hvor hurtigt den skal rulles ud, og slukke den lige så nemt.
De tre hovedanvendelser
Feature flags bruges først og fremmest til tre ting, og alle tre mindsker risikoen.
- Gradvis udrulning. I stedet for at tænde en ny funktion for alle på én gang slås den først til for en lille andel af brugerne. Ser alt godt ud, udvides den trinvis. Dukker der problemer op, er kun en brøkdel blevet berørt, og funktionen kan slukkes før den når ud til flere.
- Test med udvalgte kunder. En funktion kan tændes kun for en pilotgruppe, f.eks. et par udvalgte kunder eller ens egne medarbejdere, som får lov at prøve den i produktion og give feedback før den åbnes for alle. Man tester i virkeligheden, men i kontrolleret skala.
- Panikknap ved fejl. Viser en nyligt udgivet funktion sig at drille, kan den slukkes øjeblikkeligt med et klik. Man slipper for at skynde sig at få et hotfix ud og udgive ny kode under pres: Funktionen bliver bare slået fra indtil fejlen er undersøgt i ro og mag.
Et konkret scenarie
Lad os sige at en betalingstjeneste skal tilføje en ny betalingsmetode. Koden idriftsættes, men bag et slukket feature flag: Ingen brugere ser noget endnu. Teamet tænder det først for sine egne medarbejdere, som tester hele flowet i produktion. Alt virker.
Derefter tændes det for fem procent af kunderne. Tallene ser gode ud, og andelen øges trinvis til alle. Var noget gået galt undervejs, ville flaget være blevet slukket på et sekund, uden panik og uden en ny release. Samme funktion, men rullet ud med kontrol i hvert trin i stedet for ét stort spring der ikke kan gøres om.
Forskellen på at idriftsætte og at lancere
Det scenarie viser måske den vigtigste pointe: Feature flags adskiller idriftsættelse fra lancering.
At idriftsætte er at lægge den nye kode ud i produktionsmiljøet. At lancere er at gøre funktionen tilgængelig for brugerne. Uden flag er det den samme begivenhed: koden ud, funktionen live, i samme øjeblik, ofte sent om aftenen for at begrænse skaden hvis noget går galt. Med flag kan koden idriftsættes slukket når som helst, og funktionen tændes senere på et valgt tidspunkt. Det gør hver ændring roligere og mindre risikabel, og det er en stor del af værdien.
Advarslen om vedligehold: ryd op i gamle flag
Der er en bagside man bør kende. Hvert feature flag er en forgrening i koden, et “hvis flaget er slået til, så gør sådan her, ellers sådan her”. Så længe der er brug for flaget, er det fint. Men når en funktion først er rullet helt ud til alle, har flaget gjort sit arbejde, og bliver det alligevel liggende, roder det koden til.
Mange glemte flag gør koden sværere at læse og lettere at lave fejl i, en form for teknisk gæld der vokser i stilhed. Et ansvarligt team rydder derfor op i flag der har udspillet deres rolle så kun de aktive er tilbage. Det er ikke noget at bekymre sig om, men det er en af de ting der adskiller disciplineret udvikling fra sjusket. Vil I have en neutral vurdering af hvordan jeres system bliver passet på den slags punkter, så kontakt os.
Ofte stillede spørgsmål
Hvad er et feature flag, forklaret enkelt?
Det er en afbryder bygget ind i softwaren som styrer om en bestemt funktion er slået til eller fra. I stedet for at en ny funktion aktiveres for alle i samme øjeblik den udgives, kan man med et flag slå den til for hvem man vil, når man vil uden at røre koden igen. Funktionen er der allerede; flaget afgør bare om den er tændt.
Hvad bruges feature flags til?
Først og fremmest tre ting. Gradvis udrulning: En ny funktion slås først til for nogle få procent af brugerne og udvides hvis alt ser godt ud. Test med udvalgte kunder: En funktion tændes kun for en pilotgruppe. Og som panikknap: Går noget galt, kan funktionen slukkes med det samme uden at man skal skynde sig at få et hotfix ud. Det hele sker med et enkelt skift i stedet for en ny release.
Hvad er forskellen på idriftsættelse og lancering?
Idriftsættelse er at lægge ny kode ud i produktionsmiljøet. Lancering er at gøre funktionen tilgængelig for brugerne. Uden feature flags sker de to ting samtidig. Med flag kan man idriftsætte koden slukket og tænde den senere, f.eks. på et bestemt tidspunkt eller efter en test. Det fjerner stressen fordi kode og synlig funktion ikke længere behøver at ske i præcis samme øjeblik.
Kan feature flags skabe problemer?
Ja, hvis de ikke bliver passet. Hvert flag er en forgrening i koden, og et flag der bliver liggende længe efter at funktionen er rullet helt ud, gør koden sværere at læse og mere skrøbelig. Mange glemte flag bliver en form for teknisk gæld. Løsningen er enkel, men kræver disciplin: Ryd op i de flag der har gjort deres arbejde så kun de flag som der virkelig er brug for, bliver tilbage.
Er feature flags noget jeg som kunde behøver at interessere mig for?
Ikke i detaljer, men det er godt at kende til. At et team bruger feature flags, er som regel et godt tegn: Det betyder at de kan udgive nyt forsigtigt og hurtigt slukke for noget der driller, hvilket sænker risikoen ved hver ændring. Det du kan spørge efter, er hvordan nye funktioner rulles ud, og hvor hurtigt en fejlende funktion kan slås fra hvis det bliver nødvendigt.