Hva er et feature flag?

Feature flags er et av knepene som skiller et modent utviklingsteam fra et som slipper nye funksjoner og krysser fingrene. Begrepet høres teknisk ut, men ideen er hverdagslig: en bryter. Her går vi gjennom hva et feature flag er, hva det brukes til, og hvorfor det er verdt å kjenne til også for deg som kunde.

Definisjonen

Et feature flag, noen ganger kalt feature toggle, er en bryter som bygges inn i koden, og som slår en funksjon på eller av uten at en ny versjon må slippes. Funksjonen er på plass i programvaren, men flagget avgjør om den er synlig og aktiv eller ikke.

Det høres enkelt ut, og det er det. Men effekten er stor: Det bryter koblingen mellom at koden finnes, og at funksjonen er slått på. I stedet for at en ny funksjon uunngåelig går live i samme sekund som den slippes, kan teamet bestemme nøyaktig når, for hvem og hvor raskt den skal rulles ut, og slå den av like enkelt.

De tre hovedbruksområdene

Feature flags brukes først og fremst til tre ting, og alle tre reduserer risiko.

1. Gradvis utrulling. I stedet for å slå på en ny funksjon for alle på én gang slår man den først på for en liten andel av brukerne. Ser alt bra ut, utvides den trinnvis. Dukker det opp problemer, er bare en brøkdel berørt, og funksjonen kan slås av før den når flere.
2. Testing med utvalgte kunder. En funksjon kan slås på bare for en pilotgruppe (et par utvalgte kunder eller egne ansatte), som får prøve den i produksjon og gi tilbakemeldinger før den åpnes for alle. Man tester under reelle forhold, men i kontrollert omfang.
3. Nødbryter ved feil. Viser det seg at en nylig sluppet funksjon skaper trøbbel, kan den slås av umiddelbart med ett klikk. Man slipper å lage en rettelse i all hast og legge ut ny kode under press. Funksjonen blir bare slått av til feilen er undersøkt i ro og mak.

Et konkret scenario

La oss si at en betalingstjeneste skal legge til en ny betalingsmåte. Koden produksjonssettes, men bak et avslått feature flag, så ingen brukere ser noe ennå. Teamet slår det først på for sine egne ansatte, som tester hele flyten i produksjon. Alt fungerer.

Deretter slås det på for fem prosent av kundene. Statistikken ser bra ut, og andelen økes trinnvis til alle. Hadde noe gått galt underveis, hadde flagget blitt slått av på sekundet, uten panikk og uten ny versjon. Samme funksjon, men rullet ut med kontroll i hvert steg i stedet for i ett stort og ugjenkallelig hopp.

Forskjellen på å produksjonssette og å lansere

Scenarioet viser kanskje det viktigste poenget: Feature flags skiller produksjonssetting fra lansering.

Å produksjonssette er å legge ut den nye koden i produksjonsmiljøet. Å lansere er å gjøre funksjonen tilgjengelig for brukerne. Uten flagg er det én og samme hendelse: koden ut, funksjonen live, i samme øyeblikk, ofte sent på kvelden for å begrense skaden hvis noe går galt. Med flagg kan koden produksjonssettes når som helst med flagget slått av, og funksjonen kan slås på senere, på et valgt tidspunkt. Det gjør hver endring roligere og mindre risikabel, noe som er en stor del av verdien.

Vedlikeholdet: Rydd bort gamle flagg

Det finnes en bakside man bør kjenne til. Hvert feature flag er en forgrening i koden, en «hvis flagget er på, gjør slik, ellers slik». Så lenge flagget trengs, er det bra. Men når en funksjon først er fullt utrullet til alle, har flagget gjort jobben sin, og blir det likevel liggende, forsøpler det koden.

Mange glemte flagg gjør koden vanskeligere å lese og lettere å gjøre feil i. Det er en form for teknisk gjeld som bygger seg opp i det stille. Et ansvarlig team rydder derfor bort flagg som har spilt ut sin rolle slik at bare de aktive blir igjen. Det er ikke noe å bekymre seg for, men det er noe av det som skiller disiplinert utvikling fra slurv. Vil dere ha en nøytral vurdering av hvordan systemet deres vedlikeholdes på slike punkter, ta kontakt.