Hur du hanterar föråldrade feature flags

Att inte städa upp feature flags kan introducera risk i din kodbas. Lär dig hur en Feature Flag Removal Day kan leda till bättre feature management.

Feature flags (även kallade funktionsväxlingar) är en guldstandard inom smidig programvaruutveckling och kontinuerlig integration av goda skäl: de hjälper team att leverera nya funktioner till kunder på ett säkert sätt, och med bättre kontroll. Om du någonsin har behövt validera ny funktionalitet med slutanvändare, snabbt rulla tillbaka en ändring eller köra ett A/B-test på en funktion, är du kanske också ett fan av feature flags. De hjälper till att avrisa funktionslanseringar och koddistribution.

Men som DevOps-ingenjör kan hanteringen av feature flags också ge dig huvudvärk. När de hanteras dåligt kan du sluta med en kodbas översållad med gamla, bortglömda feature flags som faktiskt introducerar risk.

En Feature Flag Removal Day är ett enkelt, effektivt sätt att hantera feature flags ansvarsfullt.

Feature flagging låter dig rulla ut kod snabbt och säkert. Men när ditt experiment är slutfört eller utrullningen är fullständigt distribuerad utan möjlighet till tillbakarullning, bör en ingenjör ta bort den som en bästa praxis för feature flags. 

Att inte göra det öppnar för möjligheten att exponera dina kunder för fel funktion eller för funktionalitet som förstör kodbasen.

Med det sagt kan det vara svårt att prioritera att hantera feature flags, och ägarskapet är inte alltid tydligt. Du kan sätta utgångsdatum för dina feature flags, men utvecklare kan bli överlupna med andra projekt, lämna teamet eller bara behöva upprepade, vänliga knuffar för att prioritera borttagning. Feature Flag Removal Day kan hjälpa dig att skära igenom allt detta.

Feature Flag Removal Day är en dag varje månad då utvecklare svärmar samman för att ta bort feature flags som har slutfört sitt jobb. Sessionen varar vanligtvis 4-6 timmar — vi beställer munkar för att hålla energin hög! Hos Optimizely kommer vissa squads samman för att ta bort flags som en grupp; andra tilldelar en enda utvecklare ansvaret för uppgiften. 

Målet är inte nödvändigtvis att få alla flags borttagna under sessionen. Vi använder tiden till att granska utgångna feature flags, kontrollera att exit-kriterierna har uppfyllts och tilldela ägare.

Att utse en specifik dag ger utvecklare en bestämd tid att svärma samman för att hjälpa till att godkänna Pull Request-ändringarna för att ta bort sina feature flags.

Den har också följande fördelar:

Målet är att ta bort alla feature flags som inte längre aktivt används som del av ett experiment eller en utrullning.

På vår första Feature Flag Removal Day hos Optimizely utvärderade vi varenda flag som passade följande kriterier:

Vi identifierade 11 flags som matchade dessa kriterier.

Vi pratade med Product Owner för varje funktion för att säkerställa att de kunde tas bort. Vi hittade två som inte borde tas bort (den ena var en kill switch, den andra upprätthöll en äldre funktion för vissa kunder). Vi uppdaterade dessa flaggor med ett exit-kriterium och lämnade deras utgångsdatum tomt. 

Vi undersökte de återstående nio. 

En del av koden hade redan tagits bort, men flaggorna fanns fortfarande listade i dashboarden för vårt feature flagging-system. Dessa arkiverade vi och lät det vara med det.

Några få feature flags var svårare att ta bort eftersom de var distribuerade genom hela kodbasen och krävde flera utvecklare från olika produktteam för att tas bort. Dessa tog längre tid än en dag och flera code reviews att ta bort.

Men majoriteten av flaggorna togs bort enkelt och rent.

Bonus: Praktiken att ta bort flags gav utvecklare ett annat perspektiv på bästa praxis för att implementera dem. Att placera dem högre i kodbasen och ta ut dem tidigare gör dem lättare att riva ut senare.

Vår bästa praxis för feature flags inkluderar nu ett exit-kriterium och ett utgångsdatum. Dessa markörer hjälper oss att hantera hur och när vi tar bort våra flaggor. 

Exit-kriteriet är ett villkor som kvalificerar feature flaggen för borttagning. Om ett flag till exempel har rullats ut till allmänheten på 100 % och inga större buggar har rapporterats, kan det tas bort om 30 dagar (utgångsdatumet).

Vi sätter detta exit-kriterium när vi skriver acceptanskriterierna för funktionen, som en överenskommelse mellan:

Vår borttagningsprocess ser ut så här:

Att avsätta en dedikerad dag en gång i månaden hjälper till att bygga en praxis för att granska varje feature flag i kodbasen med jämna mellanrum för att säkerställa att endast de rätta flaggorna är live. Detta har gett vårt engineering-team bättre insyn i antalet flags i omlopp, och hjälper oss att mäta work in progress (WIP) som del av vår smidiga produktlednings- och utvecklingsprocess. Genom att aktivt granska våra feature flags på Feature Flag Removal Day säkerställer vi att Optimizely säkert och snabbt kan släppa produkt, samtidigt som vi håller kodbasen säker och ren. 

Om du vill komma igång med feature management kan du kolla in Optimizely  gratis feature flagging för obegränsade feature flags och kontrollerade utrullningar.