Wat is een feature flag: typen, technical debt & cleanup

Een feature flag is een voorwaarde in uw code die bepaalt of een bepaald gedrag aan of uit staat, zonder een nieuwe deploy. Dat is het hele idee. Wat is een feature flag in de praktijk? Een if statement waarvan het antwoord uit config, een databaserij of een flag service komt, in plaats van hardcoded te zijn.

Het concept is eenvoudig. Leven met 200 ervan in een repo is niet, en dat tweede gedeelte is waar deze gids werkelijk over gaat.

Hoe ziet een feature flag er in code uit?

Hier is de kleinste bruikbare versie:

if (flags.isEnabled("new-checkout", { userId })) {
  return renderNewCheckout();
}
return renderOldCheckout();

Beide code paths worden in dezelfde build verzonden. De flag value bevindt zich op een plek die u kunt wijzigen zonder opnieuw in te zetten: een omgevingsvariabele, een JSON-bestand, een tabel of een gehoste service. Wijzig de waarde en het gedrag verandert bij de volgende evaluatie.

Die scheiding is het punt. Deployment is code op servers zetten. Release is gebruikers het laten zien. Flags splitsen deze twee gebeurtenissen, dus mergen naar main betekent niet langer "iedereen krijgt dit nu".

Waarom gebruiken teams feature flags?

Drie redenen komen keer op keer terug in echte teams van 5 tot 50 engineers.

• Onvoltooide werk veilig samenvoegen. U commit de half-gebouwde feature achter een flag die uit staat, en uw branch leeft niet drie weken. Dit is wat trunk-based development werkbaar maakt.

• Geleidelijk uitrollen. Schakel een wijziging in voor interne gebruikers, dan 5% van het verkeer, dan iedereen. Als foutpercentages omhoog gaan, schakelt u het in seconden terug.

• Iets snel doodmaken. Wanneer een betalingsprovider om 2 uur 's nachts zich misbehaayt, laat een flag on-call één feature degraderen in plaats van een volledige release terugrollen.

Geen van deze vereisen een leverancier. Een flag kan een boolean in een config tabel zijn. Sla het platform over totdat u percentagerollouts, audittrails of niet-engineers nodig hebt die dingen kunnen omschakelen.

Wat zijn de vier types feature flags?

Pete Hodgson's wijdverbreid geciteerde feature toggles artikel op Martin Fowler's site sorteert flags op hoe lang ze leven en hoe vaak de beslissing verandert. De categorieën zijn nog steeds het helderste mentale model.

• Release: leeft dagen tot weken, omgeschakeld door engineers. Voorbeeld: verberg een onvoltooide checkout redesign.

• Experiment: leeft weken, omgeschakeld door product en data. Voorbeeld: een A/B-test van twee prijspagina's.

• Ops: leeft uren tot eeuwig, omgeschakeld door on-call. Voorbeeld: een kill switch voor een langzame aanbevelingsservice.

• Permission: leeft maanden tot jaren, omgeschakeld door product en support. Voorbeeld: beta-access of premium-only features.

De levensduur kolom is het meest belangrijk. Een release flag die langer leeft dan zijn release is een bug die u nog niet hebt gevonden. Een permission flag die in een cleanup sprint wordt verwijderd is een outage die u nog niet hebt gehad.

Geef de type naam en label wanneer u de flag aanmaakt. Zes maanden later herinnert niemand zich meer welke categorie "new-nav-v2" was.

Hoe rolt u een flag uit zonder gebruikers te kwetsen?

De saaie volgorde werkt het best.

1. Zend de code met de flag uit. Verifieer dat er niets is veranderd.

2. Zet het in voor uw eigen team in productie. Gebruik het een dag.

3. Zet het in voor 1% tot 5% van de gebruikers, kleverig per gebruikers-ID zodat niemand tussen varianten wisselt mid-sessie.

4. Controleer foutpercentage, latency en één zakelijke metric. Bepaal de drempel voordat u begint, niet terwijl u naar een dashboard staart.

5. Schaal tot 100%, wacht een bepaalde periode, verwijder dan de flag.

Stap vijf is degene die teams overslaan. We zullen zien waarom dat meer kost dan u denkt.

Een praktische opmerking over evaluatie: maak flag reads goedkoop en failure-safe. Als de flag service uit is, heeft uw code een standaard nodig. Kies de standaard per flag, met opzet. Een kill switch moet naar "safe" falen, terwijl een nieuwe feature naar "uit" moet falen.

Waarom worden feature flags technische schuld?

Elke flag is een vertakking in uw code. Twee flags maken vier mogelijke paden, tien flags maken 1024, en u hebt waarschijnlijk een handvol ervan getest. GrowthBook's engineering gids voor flag schuld citeert onderzoek dat aantoont dat ongeveer 75% van toggle componenten nog steeds in codebases zaten tot 49 weken nadat ze waren ingevoerd, hoewel de meeste developers zeiden dat ze van plan waren ze te verwijderen.

Hodgson put het goed in hetzelfde Fowler artikel: slimme teams behandelen toggles als inventaris met een draagkost, en werken om die inventaris laag te houden.

Het klassieke griezelhalentverhaal is Knight Capital in 2012. Een verouderde feature's flag werd hergebruikt voor nieuw gedrag terwijl oude code nog op één server zat. Die mismatch droeg bij aan ongeveer 460 miljoen dollar verlies in minder dan een uur. Uw verouderde flag zal dat waarschijnlijk niet doen. Het zal iets stiller doen: een refactor die een branch breekt die niemand wist dat het bestond, of een nieuwe medewerker die een middag doorbrengt met uitzoeken welke van twee checkout paden echte is.

Hoe vindt u elke flag in een bestaande codebase?

Dit is de vraag die de leverancierdocs overslaan, en het is waar de meeste teams vastlopen. Het flag dashboard vertelt u wat geconfigureerd is. Het vertelt u niet waar elke flag in code wordt gelezen, of de code path achter een "uit" flag nog bereikbaar is.

Begin met de goedkope benadering:

# elke letterlijke flag key gelezen via uw wrapper
rg -n 'isEnabled\("' src/ | sort

# flags defined but never referenced
comm -23 <(jq -r 'keys[]' flags.json | sort) \
         <(rg -o 'isEnabled\("([^"]+)"' -r '$1' src/ | sort -u)

Dit breekt snel af. Flag keys die zijn opgebouwd uit string concatenatie verschijnen niet in grep. Flags doorgegeven via helper functies verbergen hun call sites. Monorepo's en multi-repo setups vermenigvuldigen het probleem, omdat dezelfde key door drie services kan worden gelezen.

Dat is waar code lezen met tooling helpt. Code search tools die uw repo begrijpen kunnen "waar wordt new-checkout geëvalueerd en wat hangt af van het resultaat?" in één query beantwoorden in plaats van een middag grep. Cursor en GitHub Copilot doen dit redelijk goed in één repo. Over meerdere repo's hebt u een index nodig die ze allemaal omvat, wat het geval is waarvoor we codebasechat hebben gebouwd.

Wat ziet een gezond flag cleanup proces eruit?

Behandel verwijdering als onderdeel van het werk, niet als een klus voor later.

• Maak het verwijderingticket met de flag. Link het in de flag beschrijving. Als het ticket niet bestaat, zend de flag niet.

• Stel een eigenaar en een vervaldatum in voor elke niet-permanente flag. Rond 90 dagen zonder wijziging is een redelijke trigger voor review.

• Verwijder in twee pull requests. Verwijder eerst de flag check en houd het winnende path. Verwijder dan de dode branch en zijn tests. Kleine diffs zijn reviewable diffs.

• Voeg een time bomb test toe. Een test die faalt wanneer een release flag zijn vervaldatum voorbijgaat maakt een goeie bedoeling in een rode build.

• Zet een maximum. Als u 40 actieve flags hebt en de limiet is 40, betekent het toevoegen van één het verwijderen van één.

Statische analyse helpt hier ook. Een tool als CodeScene kan aangeven welke bestanden de meeste ingewikkelde voorwaardelijke logica dragen, wat meestal waar oude flags zich cluster. SonarQube vlaggen onbereikbare en dode code nadat u een controle hebt verwijderd.

Hoe test u code die achter een flag zit?

Testen is het gedeelte dat niemand budget voor. Met twee paths per flag moet uw testsuite beide dekken, op zijn minst voor de flags die riskant gedrag bewaken.

Hou het praktisch. Test de aan- en uittoestanden van elke release flag in unittests door de flag value in te voeren in plaats van een live service te lezen. Voer één end-to-end suite uit tegen de standaard productieconfiguratie, omdat dat is wat gebruikers vandaag krijgen. Voer dan een tweede pass uit met de flag aan voor de feature die u op het punt staat vrij te geven.

Probeer niet elke combinatie te testen. Met tien flags kunt u niet. In plaats daarvan houden flags onafhankelijk: een flag die gedrag alleen verandert wanneer een ander flag ook aan is, is een design smell, en het is het eerste wat u moet ontwarren.

Wat krijgen nieuwe engineers fout over flags?

Junioren maken gelijkaardig dezelfde drie fouten, en elk is goedkoop om in review te voorkomen.

• Flags nesten. Eén flag binnen een ander creëert een path die alleen bestaat wanneer beide aan zijn. Vraag in plaats daarvan om een enkele flag met een duidelijke naam.

• Logica in de flag naam stoppen. Een sleutel als "show-new-nav-to-premium-users-in-eu" codeert een targeting rule die in de flag service hoort, niet in een string.

• De standaard vergeten. Als de flag lookup faalt, wat gebeurt er? Laat de auteur het antwoord in de pull request beschrijving schrijven.

De eerste twee weken van een nieuwe medewerker zijn precies wanneer ze tegen oude flags lopen zonder eigenaar. Een korte flag registry, met een type, een eigenaar en een verwijderingsdatum voor elk item, bespaart meerdere uren vragen rond.

Wanneer moet u feature flags overslaan?

Flags zijn niet gratis, dus sla ze over wanneer:

• De wijziging is klein, omkeerbaar en één deploy weg van een rollback. Een flag voegt een code path toe voor geen winst.

• De wijziging raakt een databaseschema op een manier die een flag niet kan verbergen. Gebruik expand-and-contract migraties in plaats daarvan.

• Uw team heeft geen proces voor het verwijderen van flags. Repareer dat eerst, anders leent u tegen toekomstige leesbaarheid.

En gebruik ze zonder aarzeling wanneer een wijziging riskant, gebruikersgericht en moeilijk terug te draaien door opnieuw in te zetten is. Betalingsstromen, auth veranderingen en alles met een datamigratie erachter kwalificeren allemaal.

Wat zouden we echt doen op een team van tien

Begin met een boolean in config en één wrapper functie, dus elke flag read gaat door één plaats. Dat enkele knelpunt maakt de flag list greppable, auditable en gemakkelijk later om te migreren naar een gehoste service.

Label elke flag op type, geef het een eigenaar en file het verwijderingticket op dag één. Review de lijst maandelijks voor tien minuten. Verwijder de flags die twee weken op 100% zijn geweest.

Een feature flag is een lening. Neem het wanneer het u een riskante release bespaart, en betaal het terug voordat de rente in uw volgende refactor verschijnt.