Funksjonsflagg

Et funksjonsflagg, også kalt en funksjonsveksler, er en betingelse i applikasjonskode som avgjør under kjøretid om en bestemt funksjonalitet er aktiv for en gitt bruker eller forespørsel. I stedet for at en funksjon er til stede eller fraværende avhengig av hvilken versjon av koden som er distribuert, er den til stede i koden, men slått på eller av av konfigurasjon. Dette frikobler distribusjon fra utgivelse: kode kan sendes til produksjon kontinuerlig, mens funksjonene den inneholder forblir usynlige inntil noen bestemmer seg for å eksponere dem.

For eksperimentering er funksjonsflagg den underliggende mekanismen for testing på serversiden. Å tilordne en bruker til en flaggvariant er funksjonelt det samme som å tilordne dem til en eksperimentarm, og fordi avgjørelsen skjer i applikasjonen i stedet for i nettleseren, kan varianten påvirke alt applikasjonen kontrollerer: prislogikk, søkerangering, anbefalingsalgoritmer, e-postutløsere, utsjekkingsregler og backend-atferd som ingen testverktøy på klientsiden kan nå. Det eliminerer også den visuelle flimringen som manipulasjon på klientsiden produserer, og det er usynlig for annonseblokkering og skriptblokkerende nettleserinnstillinger.

Flagg tjener flere forskjellige formål som er verdt å skille mellom, fordi de har svært ulik levetid. Utgivelsesflagg skjuler uferdig arbeid og fjernes når funksjonen er fullstendig lansert. Eksperimentflagg kontrollerer varianttildeling og fjernes når testen er avsluttet. Driftsflagg, noen ganger kalt kill switches, lar en funksjon deaktiveres umiddelbart hvis den forårsaker problemer i produksjonen, og kan vare på ubestemt tid. Tillatelsesflagg begrenser funksjonalitet etter kundenivå eller kontrakt og er i praksis permanente. Å behandle alle fire som det samme er hvordan organisasjoner ender opp med hundrevis av foreldede betingelser som ingen tør å fjerne.

Denne akkumuleringen er den største risikoen. Hvert flagg er en gren, og antallet mulige kodestier vokser multiplikativt etter hvert som flagg akkumuleres. Testing av hver kombinasjon blir umulig, uventede interaksjoner mellom flagg forårsaker feil som er vanskelige å reprodusere, og koden blir stadig vanskeligere å resonnere rundt. Disiplinerte team behandler fjerning av flagg som en del av definisjonen av ferdig, fører en oversikt med en eier og en utløpsdato for hvert flagg, og reviderer regelmessig flagg som har hatt en fast verdi i flere måneder.

Funksjonsflagg muliggjør også utgivelsesstrategier som reduserer risiko uavhengig av eksperimentering. Progressiv utrulling eksponerer en funksjon for én prosent av trafikken, deretter fem, deretter tjue, med overvåking av feilrater og forretningsmålinger i hvert trinn. Ringbasert utrulling eksponerer først interne brukere, deretter en betakohort, deretter alle. Canary-utgivelser kjører en ny versjon ved siden av den gamle og sammenligner driftsmålinger før de fortsetter. Alle disse er variasjoner av den samme funksjonen: muligheten til å endre hvem som ser hva uten å distribuere kode.

Flagg fungerer også som mekanisme for kontrollert regional og segmentert utrulling, noe som er viktig for organisasjoner som opererer på tvers av flere markeder. En endring kan først eksponeres i ett enkelt land, overvåkes for markedsspesifikke problemer som involverer språk, betalingsmetoder, skattevisning eller regulatoriske krav, og deretter utvides når den er bevist. Dette er betydelig tryggere enn en global utgivelse, og det gir bevis for om en forbedring overføres mellom markeder, noe som ofte antas og sjelden testes. Verktøyspørsmålet følger av skala: små team kan administrere flagg med konfigurasjonsfiler og et enkelt administrativt grensesnitt, mens organisasjoner som kjører mange samtidige flagg på tvers av flere tjenester generelt trenger en dedikert administrasjonsplattform som tilbyr målrettingsregler, revisjonslogger og konsekvent evaluering på tvers av backend og frontend, siden inkonsekvent evaluering mellom lag produserer brukere som ser halvparten av en funksjon.

Å introdusere flagg er ofte en forutsetning før en seriøs eksperimenteringspraksis i det hele tatt kan eksistere, spesielt for funksjonalitet som ligger i applikasjonslaget snarere enn presentasjonslaget. produktutvikling I arbeidet bygges flagginfrastrukturen vanligvis langs leveringsrørledningen, slik at eksperimentering, progressiv utrulling og nødrollback alle bruker samme mekanisme. Når den først eksisterer, CRO-tjeneste Programmet er ikke lenger begrenset til hva som kan endres i nettleseren, noe som vanligvis åpner opp de mest verdifulle testideene i etterspørselen: de som involverer prising, personaliseringslogikk og mekanikken i selve kjøpsflyten.