Funktionsflag

Et funktionsflag, også kaldet en funktionsskifte, er en betingelse i applikationskode, der under kørsel bestemmer, om en bestemt funktionalitet er aktiv for en given bruger eller anmodning. I stedet for at en funktion er til stede eller fraværende afhængigt af hvilken version af koden der implementeres, er den til stede i koden, men aktiveret eller deaktiveret via konfiguration. Dette afkobler implementering fra udgivelse: kode kan sendes kontinuerligt til produktion, mens de funktioner, den indeholder, forbliver usynlige, indtil nogen beslutter at eksponere dem.

Til eksperimenter er funktionsflag den underliggende mekanisme for serversidetestning. At tildele en bruger til en flagvariant er funktionelt det samme som at tildele dem til en eksperimentarm, og fordi beslutningen sker i applikationen snarere end i browseren, kan varianten påvirke alt, hvad applikationen kontrollerer: prislogik, søgerangering, anbefalingsalgoritmer, e-mail-triggere, checkout-regler og backend-adfærd, som intet testværktøj på klientsiden kan nå. Det eliminerer også den visuelle flimmer, som manipulation på klientsiden producerer, og det er usynligt for annonceblokkere og scriptblokerende browserindstillinger.

Flag tjener flere forskellige formål, der er værd at adskille, fordi de har meget forskellige levetider. Udgivelsesflag skjuler ufærdigt arbejde og fjernes, når funktionen er fuldt lanceret. Eksperimentflag styrer varianttildeling og fjernes, når testen afsluttes. Driftsflag, undertiden kaldet kill switches, tillader, at en funktion deaktiveres øjeblikkeligt, hvis den forårsager problemer i produktionen, og kan fungere på ubestemt tid. Tilladelsesflag regulerer funktionalitet efter kundeniveau eller kontrakt og er reelt permanente. Ved at behandle alle fire som det samme ender organisationer med hundredvis af forældede betingelser, som ingen tør fjerne.

Denne akkumulering er den primære risiko. Hvert flag er en gren, og antallet af mulige kodestier vokser multiplikativt i takt med at flag akkumuleres. Test af hver kombination bliver umulig, uventede interaktioner mellem flag forårsager defekter, der er svære at reproducere, og koden bliver gradvist sværere at ræsonnere over. Disciplinerede teams behandler fjernelse af flag som en del af definitionen af ​​"færdig", fører en opgørelse med en ejer og en udløbsdato for hvert flag og reviderer regelmæssigt flag, der har haft en fast værdi i flere måneder.

Funktionsflag muliggør også udgivelsesstrategier, der reducerer risikoen uafhængigt af eksperimentering. Progressiv udrulning eksponerer en funktion for én procent af trafikken, derefter fem, derefter tyve, hvor fejlrater og forretningsmålinger overvåges i hvert trin. Ringbaseret implementering eksponerer først interne brugere, derefter en betakohorte og derefter alle. Canary-udgivelser kører en ny version sammen med den gamle og sammenligner operationelle målinger, før de fortsætter. Alle disse er variationer af den samme funktion: muligheden for at ændre, hvem der ser hvad, uden at implementere kode.

Flag fungerer også som mekanisme for kontrolleret regional og segmenteret udrulning, hvilket er vigtigt for organisationer, der opererer på tværs af flere markeder. En ændring kan først eksponeres i et enkelt land, overvåges for markedsspecifikke problemer, der involverer sprog, betalingsmetoder, skattevisning eller lovgivningsmæssige krav, og derefter udvides, når den er bevist. Dette er betydeligt sikrere end en global udgivelse, og det producerer bevis for, om en forbedring overføres mellem markeder, hvilket ofte antages og sjældent testes. Værktøjsspørgsmålet følger af skala: små teams kan administrere flag med konfigurationsfiler og en simpel administrativ grænseflade, mens organisationer, der kører mange samtidige flag på tværs af flere tjenester, generelt har brug for en dedikeret administrationsplatform, der leverer målretningsregler, revisionslogfiler og ensartet evaluering på tværs af backend og frontend, da inkonsekvent evaluering mellem lag producerer brugere, der ser halvdelen af ​​en funktion.

Introduktion af flag er ofte en forudsætning, før en seriøs eksperimenteringspraksis overhovedet kan eksistere, især for funktionalitet, der findes i applikationslaget snarere end præsentationslaget. produktudvikling I forbindelse med arbejdet bygges flaginfrastrukturen normalt sammen med leveringspipelinen, så eksperimentering, progressiv udrulning og nødudrulning alle bruger den samme mekanisme. Når den først eksisterer, CRO-tjeneste Programmet er ikke længere begrænset til, hvad der kan ændres i browseren, hvilket typisk åbner op for de testidéer med den højeste værdi i efterslæbet: dem, der involverer prissætning, personaliseringslogik og selve købsflowets mekanik.