Functievlag

Een feature flag, ook wel feature toggle genoemd, is een voorwaarde in applicatiecode die tijdens de uitvoering bepaalt of een bepaalde functionaliteit actief is voor een specifieke gebruiker of aanvraag. In plaats van dat een functionaliteit al dan niet aanwezig is afhankelijk van de geïmplementeerde codeversie, is deze wel aanwezig in de code, maar kan deze via configuratie worden in- of uitgeschakeld. Dit ontkoppelt implementatie van release: code kan continu naar productie worden verzonden, terwijl de functionaliteiten die de code bevat onzichtbaar blijven totdat iemand besluit ze beschikbaar te maken.

Voor experimenten vormen feature flags het onderliggende mechanisme van server-side testen. Het toewijzen van een gebruiker aan een flag-variant is functioneel hetzelfde als het toewijzen aan een experimentarm, en omdat de beslissing in de applicatie zelf plaatsvindt in plaats van in de browser, kan de variant alles beïnvloeden wat de applicatie beheert: prijslogica, zoekresultaten, aanbevelingsalgoritmes, e-mailtriggers, afrekenregels en backend-gedrag dat geen enkele client-side testtool kan bereiken. Het elimineert ook de visuele flikkering die client-side manipulatie veroorzaakt en is onzichtbaar voor adblockers en scriptblokkerende browserinstellingen.

Vlaggen dienen verschillende, afzonderlijke doeleinden die het waard zijn om te onderscheiden, omdat ze een zeer verschillende levensduur hebben. Releasevlaggen verbergen onafgewerkt werk en worden verwijderd zodra de functionaliteit volledig is gelanceerd. Experimentvlaggen beheren de toewijzing van varianten en worden verwijderd wanneer de test is afgerond. Operationele vlaggen, soms ook wel kill switches genoemd, maken het mogelijk om een ​​functionaliteit direct uit te schakelen als deze problemen veroorzaakt in de productieomgeving, en kunnen onbeperkt actief blijven. Toegangsvlaggen beperken de functionaliteit op basis van klantniveau of contract en zijn in feite permanent. Door ze alle vier als hetzelfde te beschouwen, eindigen organisaties met honderden verouderde voorwaarden die niemand durft te verwijderen.

Die opeenstapeling is het grootste risico. Elke vlag is een vertakking, en het aantal mogelijke codepaden groeit exponentieel naarmate er meer vlaggen bijkomen. Het testen van elke mogelijke combinatie wordt onmogelijk, onverwachte interacties tussen vlaggen veroorzaken defecten die moeilijk te reproduceren zijn, en de code wordt steeds moeilijker te doorgronden. Gedisciplineerde teams beschouwen het verwijderen van vlaggen als onderdeel van de 'definition of done', houden een inventaris bij met een eigenaar en een vervaldatum voor elke vlag, en controleren periodiek op vlaggen die al maanden een vaste waarde hebben.

Feature flags maken ook release-strategieën mogelijk die het risico verlagen, onafhankelijk van experimenten. Bij een gefaseerde uitrol wordt een functie eerst aan één procent van het verkeer blootgesteld, vervolgens aan vijf procent, daarna aan twintig procent, waarbij de foutpercentages en bedrijfsstatistieken bij elke stap worden gemonitord. Bij een ringgebaseerde implementatie worden eerst interne gebruikers blootgesteld, vervolgens een bètagroep en daarna iedereen. Canary releases draaien een nieuwe versie naast de oude en vergelijken operationele statistieken voordat ze verdergaan. Al deze methoden zijn variaties op dezelfde functionaliteit: de mogelijkheid om te wijzigen wie wat ziet zonder code te hoeven implementeren.

Flags bieden ook een mechanisme voor gecontroleerde regionale en segmentale uitrol, wat belangrijk is voor organisaties die in meerdere markten actief zijn. Een wijziging kan eerst in één land worden geïntroduceerd, worden gemonitord op marktspecifieke problemen met betrekking tot taal, betaalmethoden, belastingweergave of wettelijke vereisten, en vervolgens worden uitgebreid zodra de verbetering is bewezen. Dit is aanzienlijk veiliger dan een wereldwijde release en levert bewijs op of een verbetering ook in andere markten wordt doorgevoerd, iets wat vaak wordt aangenomen maar zelden wordt getest. De vraag naar de juiste tools vloeit voort uit de schaal: kleine teams kunnen flags beheren met configuratiebestanden en een eenvoudige beheerdersinterface, terwijl organisaties die veel flags tegelijkertijd gebruiken voor meerdere services over het algemeen een speciaal beheerplatform nodig hebben dat targetingregels, auditlogs en consistente evaluatie biedt voor zowel de backend als de frontend. Inconsistente evaluatie tussen de verschillende lagen zorgt er immers voor dat gebruikers slechts een deel van een functionaliteit zien.

Het introduceren van vlaggen is vaak een voorwaarde voordat er überhaupt sprake kan zijn van serieuze experimenten, met name voor functionaliteit die zich in de applicatielaag bevindt in plaats van de presentatielaag. productontwikkeling Tijdens het werk wordt de vlaggeninfrastructuur normaal gesproken parallel aan de leveringspipeline gebouwd, zodat experimenten, geleidelijke uitrol en noodterugdraaien allemaal hetzelfde mechanisme gebruiken. Zodra deze infrastructuur bestaat, CRO-service Het programma is niet langer beperkt tot wat in de browser kan worden gewijzigd, waardoor doorgaans de meest waardevolle testideeën in de backlog beschikbaar komen: ideeën met betrekking tot prijsstelling, personalisatielogica en de mechanismen van het aankoopproces zelf.