8 beste praktijken voor functievlaggen die je moet kennen
Functievlaggen zijn een gamechanger voor productmanagers. Ze stellen je in staat nieuwe functies uit te brengen zonder de hoofdpijn—geen codewijzigingen, geen volledige uitrol en nul risico.
Zie ze als een schakelaar die je kunt omzetten om je product aan te passen of direct experimenten uit te voeren. Of je nu releasecycli versnelt of nieuwe ideeën test, functievlaggen geven jou de controle.
In dit artikel deel ik best practices voor het beheren van functievlaggen en laat ik zien hoe ik deze technieken heb gebruikt bij Guardian Soulmates, het datingplatform van The Guardian, om een grote herontwerpoperatie te vereenvoudigen.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Definitie: Functievlaggen verbeteren releasecycli doordat ze veilige, flexibele uitrol van functies mogelijk maken zonder codewijzigingen.
Waarom ze nuttig zijn: Duidelijke naamgevingsconventies voor functievlaggen helpen teams het doel ervan eenvoudig te begrijpen en verwarring te voorkomen.
Ze effectief gebruiken: Beheer vlaggen effectief door verouderde exemplaren op te ruimen en ervoor te zorgen dat ze eenvoudig aan of uit kunnen worden gezet.
Begin klein: Gebruik functievlaggen voor tests door te beginnen met kleine doelgroepen en op basis van feedback op te schalen om risico's tot een minimum te beperken.
Beste werkwijzen voor het beheer van functievlaggen
Om functievlaggen effectief te beheren en soepele productreleases te garanderen, is het belangrijk best practices te volgen die duidelijkheid en efficiëntie bevorderen. Hier zijn enkele belangrijke werkwijzen om in gedachten te houden:
- Gebruik een consistent systeem: Of je nu een beheertool of configuratiebestand gebruikt, zorg ervoor dat het systeem gemakkelijk te begrijpen en toegankelijk is voor alle teamleden.
- Stel duidelijke naamgevingsconventies vast: Elk type vlag (bijvoorbeeld release-, rechten- of uitschakelvlaggen) moet unieke en beschrijvende namen hebben, zodat iedereen ze begrijpt, zelfs jaren later.
- Maak het eenvoudig om vlaggen aan of uit te zetten: Vlaggen moeten eenvoudig in of uit te schakelen zijn zonder codewijzigingen of tussenkomst van ontwikkelaars.
- Ruim verouderde vlaggen op: Verwijder vlaggen die niet langer nodig zijn om rommel te voorkomen en technische schuld in je systeem te verminderen.
1. Gebruik een consistent systeem voor het beheer van functievlaggen
Het maakt niet uit of je een beheertool voor functievlaggen gebruikt (zoals bijvoorbeeld LaunchDarkly), een configuratiebestand of een databasetabel. Wat je ook gebruikt, het systeem moet gemakkelijk te begrijpen zijn en goede naamgevingsconventies bevatten, zodat elke software-engineer begrijpt wat een vlag doet.
Neem bij de eerste introductie van functievlaggen wat tijd om te bespreken welke oplossing voor jou het beste is, want je wilt dit systeem op de lange termijn blijven gebruiken.
2. Stel naamgevingsconventies vast voor verschillende soorten functievlaggen
Je kunt functievlaggen implementeren om veel verschillende dingen te bereiken:
- Releasevlaggen: maken het mogelijk om productiecode uit te rollen voordat een functie klaar is voor openbare release.
- Experimentvlaggen: bij het opzetten van een A/B-test bepaalt de vlag welke gebruikersgroep welke ervaring krijgt.
- Rechtenvlaggen: stellen je in staat de toegang tot bepaalde functies voor verschillende klanten te beheren
- Uitschakelvlaggen: stellen je in staat je product gecontroleerd te degraderen bij prestatie- of overbelastingsproblemen.
Duidelijke naamgevingsconventies voor elk type vlag zorgen ervoor dat iedereen weet wat elke vlag doet, zelfs jaren later.
3. Maak het eenvoudig om een vlag aan of uit te zetten
Het mooie van functievlaggen is dat ze eenvoudig in en uit te schakelen zijn. Idealiter heb je een manier om een vlag in te stellen zonder codewijziging of tussenkomst van een ontwikkelaar. Omdat vlaggen op zoveel manieren kunnen worden gebruikt, willen meerdere teams ze mogelijk aanpassen, bijvoorbeeld:
- QA om een bepaalde klantsituatie te onderzoeken of na te bootsen.
- De klantenservice om een functie voor een klant in of uit te schakelen.
- Het DevOps-team om (delen van) je product gecontroleerd uit te schakelen bij overbelasting of andere problemen.
Als je een online scherm hebt om de vlaggen in te stellen, kan dit allemaal worden gedaan zonder werk van je engineeringteam.
4. Maak de instellingen van functievlaggen zichtbaar
Het moet eenvoudig zichtbaar zijn welke combinatie van functievlaginstellingen voor een specifieke gebruiker is ingesteld. Dit moet samen met het profiel van de gebruiker worden opgeslagen, zowel in je gebruikersdatabase als in je analysesysteem.
Dit kan erg nuttig zijn voor de klantenservice bij het onderzoeken van gemelde problemen. Het kan ook zeer waardevol zijn om verschillende gedragingen van gebruikers met verschillende instellingen te analyseren. Dit is essentieel bij het analyseren van de resultaten van een A/B-test.
5. Ruim verouderde vlaggen op
Releasevlaggen en experimentvlaggen zijn per definitie slechts tijdelijk nodig. Plan na de volledige release van een nieuwe functie die door een vlag wordt beheerd of na afloop van een experiment tijd in om de vlag als laatste stap te verwijderen. Zo bouw je geen technische schuld op in de code en blijft je beheer van functievlaggen overzichtelijk en gemakkelijk te begrijpen.
6. Vermijd afhankelijkheden tussen vlaggen
Elke vlag moet een specifiek doel hebben dat onafhankelijk is van elke andere vlag. Voor machtigingsvlaggen betekent dit dat de code zo modulair moet zijn dat verschillende functies in elke combinatie kunnen worden ingeschakeld.
Als er meerdere vlaggen nodig zijn om een bepaald gebruiksscenario in te schakelen, of als vlaggen mogelijk conflicteren met andere vlaggen, kan het instellen van de vlaggen verwarrend worden en zullen er vroeg of laat problemen ontstaan in de gebruikerservaring.
7. Gebruik een functieschakelaar om codevertakkingen te vermijden
Wanneer je binnen het productteam de implementatie van een grotere functie bespreekt, bespreek je hoe je de softwareontwikkeling kunt opsplitsen in kleinere onderdelen. Op dat moment moet je ook het gebruik van een functievlag bespreken.
Wanneer je een vlag implementeert en deze uitgeschakeld houdt, voorkom je het creëren van langdurige functietakken. In plaats daarvan kan de code voor de nieuwe functie continu worden samengevoegd en uitgebracht zonder dat deze wordt blootgesteld aan gebruikers in een CI/CD (continue integratie / continue levering) of tijdens een Agile-sprintcode-implementatie. Dit verbetert de integriteit van je codebasis, omdat je geen grote en ingewikkelde samenvoegprocessen hebt en eventuele conflicten snel worden geïdentificeerd.
Het koppelt de release van code ook los van het tonen van de wijzigingen aan eindgebruikers, zoals uitgelegd in punt 8.
8. Gebruik functievlaggen voor kleine testreleases
Grote releases van nieuwe functies zijn vaak stressvol en riskant, maar je kunt dit aanpakken door je functie eerst aan een klein publiek beschikbaar te stellen, de effecten te monitoren en indien nodig terug te draaien.
Als je een functievlag hebt gebruikt om je code voortdurend samen te voegen en uit te brengen voordat je deze aan de wereld blootstelt, zoals aanbevolen onder punt 7, beschik je al over het hulpmiddel om dit te bereiken.
Wanneer je nieuwe functionaliteit klaar is, schakel je deze in de productieomgeving in om haar eerst alleen beschikbaar te stellen aan interne testers, vervolgens aan een klein percentage klanten (een canaryrelease genoemd) en daarna aan het volledige klantenbestand.
Bij elke stap monitor je je belangrijkste statistieken. Als er op enig moment iets misgaat, kun je de vlag eenvoudig weer uitschakelen en het probleem onderzoeken zonder de stress van een ingewikkelde terugdraaiing.
De volgende casestudy toont een voorbeeld van het beperken van de risico's bij een ingrijpend herontwerp van een product.
Casestudy - functievlaggen bij het herontwerp van Guardian Soulmates
Toen ik als productmanager voor Guardian Soulmates werkte (destijds het datingplatform met abonnement van de Guardian), stonden we voor twee uitdagingen: een mobiele site van ondermaatse kwaliteit en een verouderde huisstijl. We besloten de overgang naar een responsieve site met een nieuwe huisstijl in twee stappen aan te pakken.
Laten we eerlijk zijn: klanten hebben over het algemeen een hekel aan verandering, vooral betalende klanten. Een rebranding is een grote onderneming die veel verstoring kan veroorzaken.
We bespraken hoe we onze doelen het beste konden bereiken: de mobiele site vervangen en een nieuwe huisstijl implementeren zonder al te veel verstoring voor onze abonnees. De gekozen oplossing was een proces in twee stappen met twee functievlaggen:
- Vlag voor responsieve lay-out: deze vlag werd gebruikt om ons in staat te stellen elke afzonderlijke pagina weer te geven in een responsieve of in de bestaande desktoplay-out (de afzonderlijke mobiele site bleef ongewijzigd totdat we klaar waren om de nieuwe mobiele site volledig te lanceren).
- Vlag voor nieuwe huisstijl: met deze vlag konden we de hele site in de oude of de nieuwe huisstijl weergeven.
Vlag voor responsieve site
Na het creëren van een responsief raamwerk migreerden we de pagina's één voor één naar de nieuwe responsieve lay-out. Als je aan iets vergelijkbaars werkt, kunnen deze hulpmiddelen voor het prototypen van responsief ontwerp je helpen om lay-outs te testen en te verbeteren voordat ze live gaan.
Voor elke gemigreerde pagina werd de functievlag voor responsiviteit eerst ingeschakeld voor een kleine groep gebruikers, met een optie om feedback te geven.
Na enkele dagen werd de responsieve pagina vervolgens live gezet voor alle gebruikers. Dit werd herhaald totdat de hele site responsief was.
Vervolgens werd de mobiele site overgezet naar de nieuwe responsieve site. De verstoring voor desktopgebruikers was minimaal, omdat we de pagina's stapsgewijs hadden overgezet.
De verstoring voor mobiele gebruikers was gering, omdat we destijds niet veel mobiele gebruikers hadden (de oude mobiele site was namelijk niet erg goed!).
Vlag voor huisstijlvernieuwing van de responsieve site
Na de uitrol van de responsieve site stelde de functievlag voor de nieuwe huisstijl ons in staat om de hele site tussen de oude en nieuwe huisstijl te schakelen.
Ontwikkelaars implementeerden een knop op de site om de huisstijl per gebruiker te wijzigen, waardoor ontwerpers, QA en ook ik als productmanager de voortgang konden bekijken.
Herontworpen pagina's werden voortdurend uitgebracht, maar in de liveomgeving bleef deze vlag uitgeschakeld, zodat geen enkele gebruiker pagina's in de nieuwe huisstijl zag.
Toen alle pagina's klaar waren, plaatsten we een knop op de site waarmee gebruikers zich konden aanmelden voor een openbare preview van de nieuwe huisstijl. Met deze knop werd de nieuwe huisstijl voor een gebruiker geactiveerd. De gebruikers konden ons feedback geven en na een week schakelden we de huisstijl voor iedereen in.
Het hele proces verliep volledig probleemloos, zowel voor het ontwikkelingsteam als voor onze klanten. Het was een uitstekend voorbeeld van hoe je featureflags kunt gebruiken om de risico's van een grote herziening van een site te beperken.
Als je in meer detail wilt weten wat we hebben gedaan, kun je een artikel over het Soulmates-herontwerpproject vinden op de Engineering Blog van The Guardian.
Laatste gedachten
Zorg dat het initiële raamwerk goed is en je zult merken dat het gebruik van featureflags de flexibiliteit en efficiëntie van je product aanzienlijk kan vergroten.
Je zou ook moeten overwegen om featureflags te gebruiken voor grotere initiatieven om risico's te beperken, evenals een plan voor releasebeheer om een soepele uitrol te garanderen. Je kunt ook AI in releasebeheer gebruiken om dit plan op te stellen. De enige beperking bij het gebruik van featureflags is je verbeelding!
Vertel ons in de reacties over slimme manieren waarop je featureflags in je product hebt gebruikt.
Als je meer tips en trucs wilt om je vaardigheden op het gebied van productmanagement te verbeteren, abonneer je dan op onze nieuwsbrief.
Schakel de hulp in van een andere productmanager in je team met deze handige gids: Zo maak je een effectieve functiebeschrijving voor een agile productmanager (+voorbeeld)
Ook de moeite waard:
