Implementatie vindt plaats wanneer de code in productie komt. Vrijgave is wanneer iemand het daadwerkelijk kan gebruiken. Het verwarren van deze twee is een van de snelste manieren om van elke inzet een spannend moment te maken.
De feature flag dienen om ruimte tussen deze twee momenten te creëren. U kunt vandaag implementeren, morgen starten voor het interne team, vervolgens voor een pilotklant en vervolgens voor 10% van de gebruikers. Als er iets misgaat, zet dan de vlag uit. U hoeft niet noodzakelijkerwijs de hele release terug te draaien.
De vlag is niet alleen een als
Technisch gezien is het vaak een if. Cultureel gezien is het veel meer.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Dat kleine if kan een geleidelijke uitrol, een experiment, een migratie, een ondernemingsvergunning of een operationele kill switch vertegenwoordigen. Het probleem is dat als je het niet goed beheert, het ook technische schulden kunnen worden die twee jaar in de code blijven staan.
Waar komt OpenFeature binnen?
OpenFeature is een open specificatie voor het evalueren van feature flag met een gemeenschappelijke API. Het idee is simpel: uw applicatiecode mag niet rechtstreeks afhankelijk zijn van de leverancier of het interne systeem dat u voor vlaggen gebruikt.
De app vraagt:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
De provider bepaalt waar de regels vandaan komen: SaaS, bestand, interne service, flagd, GitOps-configuratie. Als u op een dag de backend met functiemarkeringen wijzigt, hoeft de applicatie niet overal opnieuw te worden geschreven.
Deze scheiding lijkt een architectonisch detail, maar wordt voelbaar naarmate het project groeit.
Context is het halve werk
Een aan- of uitvlag voor iedereen is handig, maar beperkt. Progressieve bezorging leeft in context:
- interne of externe gebruiker;
- gratis of ondernemingsplan;
- dorp;
- organisatie;
- app-versie;
- stabiel percentage verkeer.
De belangrijke sleutel is targetingKey: deze moet stabiel zijn. Als het bij iedere aanvraag verandert, kan een gebruiker één keer in variant A terechtkomen en één keer in variant B. Voor een experiment is het verschrikkelijk, voor een kassa kan het desastreus zijn.
Een verstandige uitrol
Een flow die ik leuk vind is deze:
- inzetten met uitgeschakelde vlag;
- ontsteking voor ontwikkelaars en QA;
- inschakelen voor een pilotklant of huurder;
- Uitrol van 5%;
- uitrol op 25%;
- 100% uitrol;
- verwijdering van oude code en vlag.
Het vaak vergeten punt is het laatste. Een tijdelijke vlag moet een overlijdensdatum hebben. Als het voor altijd blijft, zal elke toekomstige refactor zich moeten afvragen: "maar is deze tak nog bruikbaar?".
Kill switch: bereid ze eerst voor
De kill switch is de vlag die u redt wanneer een externe afhankelijkheid u in de war brengt, een taak te veel bronnen verbruikt of nieuwe logica vreemde fouten oplevert.
Een goede kill switch moet zijn:
- gemakkelijk te vinden;
- gedocumenteerd in het runbook;
- af en toe getest;
- waarneembaar wanneer geactiveerd;
- voor zover mogelijk onafhankelijk van het onderdeel dat kapot zou kunnen gaan.
Het ergste is om tijdens het ongeval te ontdekken dat de vlag bestaat, maar niemand weet of hij nog werkt.
Waarneembaarheid of niet progressieve levering
Een functie op 10% inschakelen zonder naar de statistieken te kijken is slechts optimisme met meerdere stappen.
Elke uitrol moet eenvoudige vragen beantwoorden:
- zijn de fouten toegenomen?
- is de latentie veranderd?
- voltooien gebruikers de stroom?
- zijn er meer tickets of nieuwe pogingen?
- heeft een variant slechts invloed op één segment?
OpenFeature ondersteunt haken rond vlagevaluatie. Ze zijn handig voor het loggen van fouten, het toevoegen van statistieken of het koppelen van de beoordeling aan een trace.
Naamgeving en eigendom
Namen zijn belangrijk. new_ui zegt niets. checkout.v2.enabled zegt veel meer.
Voor elke vlag zou ik minimaal het volgende markeren:
- naam;
- beschrijving;
- eigenaar;
- veilige standaard;
- reden waarom het bestaat;
- datum of voorwaarde van verwijdering.
Een vlag zonder eigenaar is bijna altijd een vlag die niemand zal ontruimen.
Waar je ze kunt evalueren
Frontend, backend of edge? Hangt ervan af.
Als de vlag bedoeld is voor lay-out, kopiëren of onboarding, is de frontend prima. Als het om machtigingen, facturering, limieten of gevoelige gegevens gaat, moet dit op de backend staan. Als het gaat om routing of experimenten met veel verkeer, kan de edge zinvol zijn.
De simpele regel: de frontend kan de ervaring verbeteren, maar mag niet de enige beveiligingsbarrière zijn.
Conclusie
De feature flag die goed zijn gedaan, veranderen de relatie met de productie. Ze elimineren het risico niet, maar maken het kleiner en beter beheersbaar. Je kunt in stukjes loslaten, observeren, stoppen, teruggaan, leren.
OpenFeature voegt een schone basis toe: een gemeenschappelijke API, uitwisselbare providers en een nettere manier om het systeem te laten groeien. Maar de discipline blijft van jou: veilige standaardwaarden, duidelijke namen, statistieken, eigenaren en netheid.
De beste vlag is degene die je helpt rustig los te laten en vervolgens verdwijnt als hij niet langer nodig is.