Feature flags maken het mogelijk om code te deployen zonder nieuwe functionaliteit direct voor iedereen beschikbaar te maken. Lees hoe verschillende soorten flags werken, hoe je ze beheert en welke technische risico’s ontstaan als tijdelijke flags permanent blijven.
Feature flags scheiden deployment van release
Een feature flag is een voorwaarde in software die bepaalt of een onderdeel van de applicatie actief is. De code kan al in productie staan, terwijl de functionaliteit nog niet zichtbaar is voor gebruikers. Daarmee ontstaan twee afzonderlijke beslissingen: wanneer code wordt gedeployed en wanneer een functie wordt gereleased. Dat onderscheid is vooral bruikbaar wanneer meerdere teams parallel werken, een functie afhankelijk is van externe systemen of een wijziging eerst op beperkte schaal moet worden gecontroleerd.
Een flag kan worden geïmplementeerd als configuratie in een centraal systeem, als omgevingsvariabele of als instelling in de applicatie zelf. De keuze beïnvloedt hoe snel wijzigingen beschikbaar zijn en hoe afhankelijk de applicatie is van externe configuratie. Een centrale dienst maakt aanpassingen vaak mogelijk zonder nieuwe deployment, maar introduceert ook een extra afhankelijkheid. Lokale configuratie kan robuuster zijn bij netwerkproblemen, maar vereist doorgaans een deployment om een waarde aan te passen.
Een flag vervangt geen releaseproces en maakt ongeteste code niet veilig. Ook verborgen code kan fouten bevatten, bijvoorbeeld tijdens initialisatie of bij interactie met bestaande functies. Daarom moet de uitgeschakelde toestand expliciet worden getest en moet de code achter de flag compatibel zijn met de productieomgeving. Het belangrijkste ontwerpbesluit is niet alleen hoe een flag wordt aangezet, maar ook hoe de applicatie zich gedraagt wanneer de configuratie ontbreekt of niet bereikbaar is.
Release flags voor gefaseerde ingebruikname
Een release flag verbergt functionaliteit die nog niet klaar is voor alle gebruikers. Een team kan de nieuwe code naar productie brengen en de functie eerst intern beschikbaar maken, daarna voor een beperkte groep en vervolgens voor een bredere doelgroep. Die aanpak verlaagt de omvang van een releasebeslissing: de code hoeft niet opnieuw te worden uitgerold om de zichtbaarheid te wijzigen. Tegelijk blijft de normale kwaliteitscontrole nodig, want productiecode kan al worden aangeroepen zodra de flag verkeerd staat.
Gefaseerde activatie vraagt om een nauwkeurige definitie van de doelgroep. Dat kan op basis van account, gebruikersrol, regio of een percentage van gebruikers. Een percentage wordt meestal toegewezen met een stabiele sleutel, zoals een account-ID. Zonder stabiele toewijzing kan dezelfde gebruiker bij ieder verzoek een andere uitkomst krijgen. Dat maakt gedrag moeilijk reproduceerbaar en kan bijvoorbeeld leiden tot een gedeeltelijk aangemaakte workflow.
Leg vooraf vast welke signalen bepalen of de uitrol verdergaat. Denk aan foutpercentages, latency, gebruik van de nieuwe functie en meldingen uit operationele monitoring. Een plotselinge activatie voor iedereen is geen vervanging voor gecontroleerde uitbreiding, vooral niet wanneer databasebelasting of externe API-aanroepen veranderen. Houd ook rekening met samenhang tussen onderdelen: als een nieuwe interface afhankelijk is van een nieuwe backendroute, moeten beide flags en hun standaardwaarden gezamenlijk worden beheerd. Anders kan een gebruiker een combinatie krijgen die technisch niet wordt ondersteund.
Experimentflags voor gecontroleerde producttests
Experimentflags verdelen gebruikers over varianten om te onderzoeken welk effect een wijziging heeft. De flag bepaalt bijvoorbeeld welke interface, tekst of volgorde iemand ziet. Anders dan bij een gewone releaseflag is niet alleen de beschikbaarheid van belang, maar ook de toewijzing aan een testgroep en de interpretatie van meetgegevens. Een experiment vereist daarom een vooraf gekozen hypothese, een relevante uitkomstmaat en een consistente manier om gebruikers gedurende de test aan dezelfde variant toe te wijzen.
Randomisatie op verzoekniveau is vaak ongeschikt. Een bezoeker kan dan tijdens één sessie tussen varianten wisselen, terwijl acties over meerdere verzoeken worden gemeten. Toewijzing op gebruikers- of accountniveau geeft doorgaans stabielere groepen, maar heeft gevolgen voor privacy, opslag en situaties waarin gebruikers niet ingelogd zijn. Bij zakelijke software is randomiseren per organisatie soms logischer, omdat collega’s binnen één account dezelfde werkwijze en interface moeten ervaren.
Ook de implementatie kan de resultaten vertekenen. Als een variant trager laadt, minder betrouwbaar is of alleen op bepaalde apparaten wordt getoond, meet een team mogelijk technische frictie in plaats van het effect van de productwijziging. Definieer daarom hoe ontbrekende data, bots, interne accounts en voortijdig beëindigde sessies worden behandeld. Bewaar de toewijzing en relevante variantinformatie op een manier die achteraf controleerbaar is. Een experimentflag hoort tijdelijk te zijn: na de analyse wordt de gekozen variant onderdeel van de normale code of wordt de test verwijderd.
Operationele flags en kill switches
Een operationele flag stuurt gedrag aan dat invloed heeft op beschikbaarheid, belasting of afhankelijkheden. Een kill switch kan bijvoorbeeld een kostbare synchronisatie, een externe integratie of een zwaar achtergrondproces uitschakelen. Dat is een ander doel dan een functie verbergen voor een doelgroep: de flag dient hier als operationeel instrument wanneer een onderdeel onverwacht problemen veroorzaakt. De waarde ervan hangt af van de vraag of de schakelaar onafhankelijk van het falende onderdeel bereikbaar blijft.
Als een centrale configuratiedienst niet beschikbaar is, moet de applicatie een bewuste terugvalkeuze maken. Voor een optionele achtergrondtaak kan uitschakelen de veiligste standaard zijn; voor authenticatie of een essentieel gegevenspad kan dezelfde standaard gebruikers buitensluiten. De keuze hoort bij de functie en moet worden vastgelegd, getest en zichtbaar gemaakt in monitoring. Een schakelaar die alleen werkt zolang de database, configuratiedienst en applicatie gezond zijn, biedt weinig bescherming bij een storing in die keten.
Operationele flags kunnen ook onverwachte neveneffecten hebben. Het uitschakelen van een integratie kan bijvoorbeeld een wachtrij laten groeien, waarna die bij herinschakeling een piek aan verzoeken veroorzaakt. Een limiet, gecontroleerde hervatting of verwerking in batches kan nodig zijn. Beperk bovendien wie operationele schakelaars mag aanpassen en registreer wijzigingen met tijdstip, actor en reden. Een flag die productiegedrag verandert zonder auditspoor maakt incidentanalyse lastiger en kan tijdens een storing extra onzekerheid veroorzaken.
Permissies en feature flags zijn verschillende mechanismen
Een feature flag wordt soms gebruikt om functionaliteit aan bepaalde accounts beschikbaar te stellen. Dat kan praktisch zijn voor een beperkte uitrol, maar een flag is niet automatisch een autorisatiemechanisme. Een verborgen knop voorkomt niet dat iemand rechtstreeks een API-verzoek doet. De server moet bij iedere beschermde actie zelfstandig controleren of de gebruiker de vereiste rechten heeft. Toegangscontrole hoort gebaseerd te zijn op identiteit, rol en beleidsregels, niet alleen op de zichtbaarheid van een interface-element.
Maak onderscheid tussen tijdelijke beschikbaarheidsregels en structurele productrechten. Een releaseflag kan bepalen of een functie technisch actief is tijdens een uitrol. Een entitlement kan bepalen welke functionaliteit een account volgens zijn configuratie mag gebruiken. Die begrippen kunnen beide als configuratie worden opgeslagen, maar hebben een andere eigenaar, levensduur en foutafhandeling. Door ze in één ongedifferentieerde vlag te combineren, wordt onduidelijk of een gebruiker geen toegang heeft vanwege een productinstelling, een releasebesluit of een autorisatiefout.
Leg vast waar de beslissing wordt genomen en welke componenten haar afdwingen. Een backend kan de autorisatie valideren terwijl de frontend dezelfde informatie gebruikt om menu’s aan te passen. De frontendweergave is dan gebruiksgemak, niet de beveiligingsgrens. Controleer ook hoe wijzigingen doorwerken in caches, sessies en achtergrondtaken. Een recht dat is ingetrokken, mag niet via een verouderde cache onbeperkt geldig blijven. Door flags, permissies en entitlements afzonderlijk te modelleren, blijven audits en incidentonderzoek beter te begrijpen.
Configuratie, evaluatie en consistent gedrag
Feature flags moeten op een voorspelbare plek worden geëvalueerd. Wanneer verschillende onderdelen zelf configuratie uitlezen en interpretaties toepassen, kunnen frontend, API en achtergrondverwerking uiteenlopende uitkomsten krijgen. Een centrale evaluatielaag kan standaardwaarden, doelgroepregels en logging samenbrengen. Dat betekent niet dat iedere beslissing afhankelijk moet zijn van één externe dienst; de applicatie kan configuratie lokaal cachen en expliciet omgaan met verouderde of ontbrekende waarden.
De configuratiestructuur moet aangeven op welke entiteit een regel van toepassing is. Een accountgerichte instelling hoort niet ongemerkt te worden overschreven door een gebruikersregel, en een omgevingsinstelling mag geen onbedoelde productievariant activeren. Leg prioriteit tussen regels vast en test grensgevallen, waaronder onbekende accounts, lege waarden en conflicterende targeting. Gebruik voor varianten een stabiele hash of expliciete toewijzing wanneer herhaalbaarheid nodig is. Zo kan hetzelfde account in logs, API-verzoeken en achtergrondtaken dezelfde beslissing krijgen.
Configuratie is bovendien softwaregedrag en verdient versiebeheer of een auditlog. Registreer wie een wijziging deed, welke waarde veranderde en op welke omgeving die betrekking had. Houd geheime gegevens buiten gewone flagconfiguratie; een vlag die per ongeluk een credential bevat, kan breder zichtbaar worden dan bedoeld. Stel ook vast hoe snel configuratiewijzigingen door caches worden overgenomen. Lange cachetijden verminderen afhankelijkheid van de configuratiedienst, maar vertragen correcties. Korte tijden versnellen aanpassing, maar kunnen bij een storing extra belasting of inconsistentie veroorzaken.
Eigenaarschap, documentatie en teststrategie
Een feature flag heeft een eigenaar nodig die verantwoordelijk is voor het doel, de doelgroep en de verwijdering. Zonder eigenaar blijft de betekenis van een vlag vaak alleen bekend bij het team dat de code schreef. Voeg daarom metadata toe zoals type, aanmaakdatum, verantwoordelijke, reden en beoogde eindconditie. Een omschrijving als tijdelijke testfunctie is onvoldoende wanneer niet duidelijk is welke beslissing de test moet opleveren of wanneer de vlag niet meer relevant is.
De teststrategie moet beide uitkomsten en belangrijke combinaties afdekken. Test de functie met de flag aan en uit, maar controleer ook wat er gebeurt wanneer configuratie ontbreekt, een provider een fout teruggeeft of targeting onvolledig is. Bij meerdere flags neemt het aantal combinaties snel toe. Niet elke combinatie hoeft als volledige integratietest te bestaan, maar kritieke afhankelijkheden moeten expliciet worden gemodelleerd. Anders kan een reeks afzonderlijk correcte instellingen samen een ongeldige toestand opleveren.
Monitoring moet waar mogelijk laten zien welke variant een verzoek heeft gebruikt, zonder onnodige persoonsgegevens te loggen. Dat maakt verschillen in fouten of prestaties onderzoekbaar. Controleer ook of dashboards en alerts onderscheid maken tussen een uitgeschakelde functie en een defecte functie. Tijdens een incident is het belangrijk te zien of de flag zelf veranderde, of dat de code achter de flag problemen veroorzaakt. Eigenaarschap omvat daarom niet alleen het schrijven van code, maar ook het volgen van gebruik, wijzigingsgeschiedenis en de uiteindelijke opruiming.
Verouderde feature flags verwijderen zonder regressies
Flags die hun oorspronkelijke doel hebben verloren, vormen technische schuld. Elke blijvende conditie maakt code moeilijker te lezen en vergroot de hoeveelheid gedrag die getest moet worden. Een vergeten releaseflag kan twee codepaden onderhouden die in werkelijkheid nog maar één relevante toestand hebben. Oude targetingregels kunnen bovendien onbedoeld een groep gebruikers op een afwijkende variant houden. Het probleem zit niet alleen in de extra regels, maar ook in de onzekerheid over welke configuratie nog productiegedrag beïnvloedt.
Verwijderen begint met vaststellen dat de vlag nergens meer nodig is. Controleer verwijzingen in applicatiecode, configuratie, infrastructuur, dashboards en scripts. Kijk vervolgens naar de werkelijk actieve waarde per omgeving en naar uitzonderingen voor specifieke accounts. Verwijder eerst de onnodige variant of maak de gekozen implementatie de standaard, en ruim daarna de flagdefinitie en eventuele targetingregels op. Bij flags die meerdere services beïnvloeden, moet de volgorde van wijzigingen rekening houden met versies die tijdelijk naast elkaar draaien.
Een vlag kan ook bewust langer blijven bestaan wanneer zij een operationele schakelaar is of een structurele beleidskeuze vertegenwoordigt. In dat geval hoort ze niet als tijdelijke releaseflag te worden behandeld: documenteer doel, bevoegdheden, foutgedrag en periodieke controle. Automatiseer waar mogelijk signalering voor flags die ouder zijn dan hun afgesproken levensduur of waarvan de codeverwijzing ontbreekt. Verwijdering zonder zicht op accountuitzonderingen kan functionaliteit onverwacht wijzigen; niets verwijderen laat daarentegen historische beslissingen permanent doorwerken. Het beheer vraagt daarom om expliciete classificatie en een gecontroleerde overgang naar de gewenste toestand.
Veelgestelde vragen
Wat is het verschil tussen feature flags en feature branches?
Een feature branch scheidt code tijdens de ontwikkeling, terwijl een feature flag bepaalt welk gedrag actief is wanneer de code al is samengevoegd en gedeployed. Met een branch houden ontwikkelaars werk tijdelijk apart in het versiebeheersysteem; met een flag kan een applicatie verschillende codepaden uitvoeren op basis van configuratie of doelgroep. Een flag voorkomt dus niet dat code wordt gedeeld of getest, maar geeft controle over de uitvoering ervan.
- Gebruik branches voor tijdelijk, parallel ontwikkelwerk.
- Gebruik flags wanneer je functionaliteit na deployment gecontroleerd wilt activeren.
Hoe verwijder je een feature flag veilig nadat een functie is uitgerold?
Verwijder een feature flag veilig door eerst te bevestigen welk codepad definitief blijft en daarna de flag, de alternatieve code en bijbehorende configuratie gecontroleerd op te ruimen. Controleer vooraf of er nog accounts, omgevingen of processen zijn die van de oude instelling afhangen. Zo voorkom je dat een vergeten doelgroep na de opruiming ander gedrag krijgt dan verwacht.
- Leg de definitieve variant vast en controleer die in productie.
- Verwijder de flagconditie en het overbodige codepad.
- Ruim targetingregels, configuratie en tests op die alleen bij de flag horen.
- Voer relevante tests uit en controleer na deployment de monitoring.
Hoeveel feature flags zijn te veel voor een applicatie?
Er is geen vast aantal feature flags dat voor iedere applicatie te veel is; het wordt problematisch wanneer teams de betekenis, eigenaar, actieve doelgroep of verwijderdatum niet meer kunnen overzien. Iedere flag voegt mogelijke codepaden en configuratie toe. Het aantal op zichzelf zegt daarom minder dan de onderhoudslast en het aantal combinaties dat getest en begrepen moet worden.
- Inventariseer periodiek flags die niet meer veranderen of geen actueel doel hebben.
- Geef tijdelijke flags een eigenaar en een moment waarop het doel opnieuw wordt beoordeeld.
- Let extra op flags die met andere flags gecombineerd worden.
- Verwijder afgeronde flags in plaats van ze permanent uit te laten staan.
Kun je feature flags gebruiken in een mobiele app?
Ja, je kunt feature flags gebruiken in een mobiele app, maar houd rekening met versies die gebruikers niet meteen bijwerken en configuratie die tijdelijk niet bereikbaar is. Een server kan een functie uitschakelen voor nieuwe verzoeken, maar code die al op een toestel staat blijft onderdeel van de app. Zorg daarom dat de applicatie ook met een oudere configuratie of zonder netwerk een veilige en bruikbare toestand behoudt.
- Bepaal welke instellingen lokaal worden bewaard en hoe lang die geldig zijn.
- Test gedrag bij een lege, verouderde of onbereikbare configuratie.
- Gebruik flags niet als vervanging voor serverzijdige autorisatie.
- Controleer of oude appversies de nieuwe configuratievelden kunnen verwerken.
Maken feature flags een applicatie trager?
Feature flags kunnen een applicatie trager maken als elke beslissing een extra netwerkverzoek vereist of als de evaluatie veel werk uitvoert. Bij lokale evaluatie met vooraf geladen configuratie is de extra vertraging doorgaans beperkt, maar de werkelijke invloed hangt af van de implementatie en het aantal evaluaties. Meet daarom de impact op responstijd en foutpercentages, vooral op paden die vaak worden aangeroepen.
- Laad configuratie waar mogelijk vooraf of gebruik een passende cache.
- Vermijd een afzonderlijke externe aanvraag voor iedere flagcontrole.
- Meet de evaluatietijd en controleer wat er gebeurt bij cachemissers.
- Houd rekening met de afweging tussen snelle configuratiewijzigingen en extra afhankelijkheden.
