Feature flags in maatwerk software.

Wat zijn feature flags?

Een feature flag is een mechanisme waarmee je functionaliteit in je software aan- of uitzet zonder een nieuwe versie te deployen. De code staat al in productie, maar is pas actief als de flag op "aan" staat. Het klinkt simpel en dat is het ook. Maar de implicaties zijn groot.

Het kernidee is de scheiding tussen deployment en release. Deployen is code naar productie brengen. Releasen is functionaliteit beschikbaar maken voor gebruikers. Traditioneel zijn dat dezelfde stap: je deployt en alles wat in die deploy zit, is direct live voor iedereen. Met feature flags ontkoppel je die twee stappen. Je deployt wanneer je wilt en je releast wanneer je er klaar voor bent.

In de praktijk is een feature flag niet meer dan een conditie in je code: als de flag actief is, toon de nieuwe functionaliteit. Zo niet, toon de oude situatie of helemaal niets. Die conditie kan gekoppeld zijn aan een configuratiewaarde, een database-record, een gebruikersgroep of een percentage van je traffic.

Waarom feature flags?

Gecontroleerd uitrollen

In plaats van een feature in een keer aan al je gebruikers te tonen, rol je het eerst uit naar een klein percentage of een specifieke klant. Dit wordt ook wel een canary release genoemd. Als er problemen opduiken, raakt het een handvol gebruikers in plaats van je hele klantenbestand. Je vangt problemen op voordat ze escaleren.

A/B-testen

Feature flags zijn de basis voor A/B-testen. Toon variant A aan de helft van je gebruikers en variant B aan de andere helft. Meet welke variant beter presteert op de metrics die ertoe doen. Zonder feature flags is A/B-testen in maatwerksoftware een technische nachtmerrie. Met flags is het een configuratiekwestie.

Kill switch

Soms gaat er iets mis na een release. Een externe API die niet meewerkt, een edge case die je niet voorzag, een performance-probleem onder productielast. Met een feature flag zet je de problematische functionaliteit in seconden uit, zonder rollback, zonder nieuwe deploy, zonder downtime.

Ontwikkelen op de hoofdbranch

Langlevende feature branches zijn een bron van merge-conflicten en integratieproblemen. Met feature flags ontwikkel je gewoon op de hoofdbranch. Code die nog niet af is, staat achter een flag en is onzichtbaar voor gebruikers. Je integreert continu, zonder risico.

Enterprise klanten op eigen tempo

In multi-tenant software willen grote klanten vaak zelf bepalen wanneer ze nieuwe functionaliteit activeren. Sommige organisaties hebben change-management processen, trainingen of interne goedkeuringen nodig voordat ze een nieuwe feature in gebruik nemen. Met permission flags geef je ze die controle zonder dat het je release-cyclus vertraagt.

Deployen is code naar productie brengen. Releasen is gebruikers er toegang toe geven. Wie dat onderscheid begrijpt, slaapt beter na elke deploy.

Soorten feature flags

Niet elke flag heeft hetzelfde doel en hetzelfde levenscyclus. Het helpt om feature flags in te delen in vier categorieen:

Release flags

Tijdelijke flags die je gebruikt om een feature geleidelijk uit te rollen. Ze bestaan vanaf het moment dat de feature in productie staat tot het moment dat de feature volledig is uitgerold. Daarna verwijder je de flag. Levensduur: dagen tot weken.

Ops flags

Operationele flags die functioneren als kill switches of maintenance toggles. Denk aan het uitschakelen van een zware achtergrondtaak tijdens piekbelasting, of het tijdelijk deactiveren van een integratie met een onstabiele externe dienst. Deze flags hebben geen geplande einddatum maar moeten wel gedocumenteerd zijn.

Permission flags

Flags die bepalen welke tenants of gebruikersgroepen toegang hebben tot specifieke functionaliteit. Dit zijn de flags voor betaalde tiers, early-access programma's of klantspecifieke features. Ze zijn langlevend en vormen een bewust onderdeel van je businesslogica.

Experiment flags

Flags voor A/B-testen en gebruikersexperimenten. Ze verdelen traffic over verschillende varianten en worden gekoppeld aan analytics om de resultaten te meten. Na afloop van het experiment verwijder je de flag en implementeer je de winnende variant.

Implementatie in Laravel

Van simpel naar geavanceerd

Voor basale feature flags volstaat een configuratie-instelling of een kolom in je database. Een simpele aan/uit-check in je applicatie is al een feature flag. Voor kleine projecten met een handvol flags is dit prima.

Voor complexere scenario's biedt Laravel ingebouwde ondersteuning voor feature flags die naadloos integreert met het framework. Je definieert features, koppelt ze aan specifieke gebruikers of tenants en bepaalt per feature voor wie de flag actief is — op basis van rol, abonnement, tenant of welk criterium je maar wilt.

Flags in de interface

In je templates toon je delen van de interface conditioneel op basis van de actieve flags. De nieuwe checkout-flow, een aangepast dashboard, een extra menu-item — alles achter een flag, zonder dat je interface een onleesbare puinhoop wordt.

Flags op route-niveau

Voor complete pagina's of secties die achter een flag moeten zitten, wordt de flag gecontroleerd voordat de pagina wordt geladen. Staat de flag uit, dan krijgt de gebruiker een andere pagina of een redirect. Zo is zowel de interface als de achterliggende logica beschermd.

Flags in de frontend

In een setup met een Vue.js frontend worden de actieve flags opgehaald via de API bij het laden van de applicatie. De frontend gebruikt ze om componenten, routes en functionaliteit conditioneel te tonen. Zo is je flag-logica consistent over je hele stack.

Valkuilen

Flag debt

De grootste valkuil is flags die niemand opruimt. Een release flag die zes maanden na volledige uitrol nog in de code zit. Een experiment flag waarvan niemand meer weet wat het experiment was. Na verloop van tijd heb je tientallen flags waarvan de helft niet meer relevant is maar niemand durft ze te verwijderen. Dit is flag debt en het maakt je codebase onnodig complex.

Testcomplexiteit

Elke flag verdubbelt theoretisch het aantal mogelijke toestanden van je applicatie. Twee flags betekent vier combinaties, vijf flags tweeendertig. In de praktijk hoef je niet elke combinatie te testen, maar je moet bewust zijn van interacties tussen flags. Twee features die afzonderlijk werken maar in combinatie problemen veroorzaken, zijn een reeel risico.

Houd flags kortlevend

Release flags en experiment flags hebben een duidelijke levenscyclus. Zodra de feature volledig is uitgerold of het experiment is afgerond, verwijder je de flag en de bijbehorende condities uit je code. Plan dit in als onderdeel van je definition of done: een feature is pas af als de flag is opgeruimd.

Documenteer alles

Elke flag heeft een eigenaar, een doel en een geplande einddatum. Documenteer dit in je codebase of je projectmanagement-tool. Zonder documentatie weet over drie maanden niemand meer waarom een flag bestaat, of het veilig is om hem te verwijderen of wat er gebeurt als je hem uitzet.

Feature flags zijn als steigers rondom een gebouw: onmisbaar tijdens de bouw, maar als ze er na oplevering nog staan, is er iets misgegaan.

Conclusie

Feature flags zijn een van die concepten die eenvoudig zijn in theorie en transformatief in de praktijk. Ze geven je de controle om software te releasen op jouw tempo, aan de juiste gebruikers, met een vangnet als het misgaat. In combinatie met een goede CI/CD-pipeline en een multi-tenant architectuur worden ze een onmisbaar onderdeel van professionele softwareontwikkeling.

De sleutel is discipline: gebruik flags bewust, documenteer ze en ruim ze op. Wie dat doet, heeft een krachtig instrument in handen om sneller te itereren, risico's te beperken en klanten de controle te geven die ze verwachten.