Så här hanterar du föråldrade feature flags

Om du inte rensar bort feature flags kan det medföra risker för din kodbas. Lär dig hur Feature Flag Removal Day kan leda till bättre funktionshantering.

Feature flags (även kallade feature toggles) är en guldstandard för agil mjukvaruutveckling 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 en A/B-testning på en funktion, kanske du också är ett fan av feature flags. De hjälper till att minska riskerna med funktionsreleaser och koddistribution.

Men som DevOps-ingenjör kan funktionshanteringen av features flags också ge dig halsbränna. När de hanteras fel kan det sluta med att kodbasen är full av gamla, bortglömda feature flags som faktiskt medför risker.

En Feature Flag Removal Day är ett enkelt och effektivt sätt att hantera feature flags på ett ansvarsfulltsätt .

En feature flags vars jobb är slutfört bör tas bort

Med feature flags kan du rulla ut kod snabbt och säkert. Men när ditt experiment är slutfört eller utrullningen har distribuerats fullt ut utan risk för återgång, bör en ingenjör ta bort den som bästa praxis för feature flags.

Om du inte gör det finns det risk för att dina kunder exponeras för fel funktion eller för funktionalitet som bryter mot kodbasen.

Med detta sagt kan det vara svårt att prioritera hanteringen av feature flags och ägarskapet är inte alltid tydligt. Du kan ställa in utgångsdatum för dina feature flags, men utvecklare kan bli överhopade med andra projekt, lämna teamet eller bara behöva upprepade, försiktiga påstötningar för att prioritera borttagning. Feature Flags Removal Day kan hjälpa dig att ta dig igenom allt detta.

Varför en dag för borttagning av feature flags?

Feature Flag Removal Day är en dag varje månad då utvecklare svärmar för att ta bort feature flags som har slutfört sitt jobb. Sessionen varar i allmänhet 4-6 timmar - vi beställer munkar för att hålla energin hög! På Optimizely samlas vissa grupper för att ta bort flaggor som en grupp; andra tilldelar en enda utvecklare att äga uppgiften.

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

Att utse en specifik dag ger utvecklarna en bestämd tid att samlas för att hjälpa till att godkänna ändringarna i Pull Request för att ta bort sina feature flags.

Det har också följande fördelar:

• En mänsklig kontroll: Du kan bygga in en mänsklig kontroll med Product Owner för att se till att varje flagga på listan ska tas bort.
• Socialiserar hygienrutiner för feature flags: Om man lämnar kvar för många flaggor i kodbasen kan det leda till teknisk skuld och göra kodbasen skör. En välpublicerad dag kan hjälpa dig att göra hela organisationen medveten om den här risken. Att ta itu med den regelbundet bör bli en del av kulturen i dina utvecklingsteam.
• Lättviktig, tillförlitlig process: Ta bort debatterna fram och tillbaka om varje flagga som ska tas bort genom att etablera en standardpraxis och en fastställd cykel. På Optimizely hjälper detta oss att undvika oron för att feature flags från tidigare anställda kan komma tillbaka för att hemsöka oss.
• Tydligt, tidsbundet ägande: Istället för att låta dina utvecklare äga en specifik feature flag för alltid, låt processen hantera det. På Feature Flags Removal Day, tilldela en utvecklare ansvaret för att ta bort den flaggan - fallet är avslutat.
• Öppenhet: Meddela hela teknikorganisationen att vissa funktionsväxlingar tas bort. Det minskar risken för att en flagga som används av ett team kan tas bort av ett annat.
• Effektiv användning av utvecklarnas tid: Avsätt en specifik tid för dina utvecklare att arbeta med att ta bort sina feature flags. Sedan kan de återgå till sin vanliga schemalagda programmering.

Vilka flaggor bör tas bort?

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

På vår första Feature Flag Removal Day på Optimizely utvärderade vi varje enskild flagga som uppfyllde följande kriterier:

• Flaggor som skapades före 2019
• Flaggor som inte har uppdaterats sedan 2019
• Flaggor som inte har en specifik målgruppsinriktning, vilket innebär att de exponeras för alla
• Flaggor som rullas ut till 100 % av användarbasen och 100 % i produktionsmiljön
  

Vi identifierade 11 flaggor som uppfyllde dessa kriterier.

Vi pratade med Product Owners 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 behöll en äldre funktion för vissa kunder). Vi uppdaterade dessa flaggor med ett exit-kriterium och ett tomt utgångsdatum.

Vi undersökte de återstående nio.

Vad vi fann

En del av koden hade redan tagits bort, men flaggorna fanns fortfarande kvar i dashboarden för vårt system för feature flags. Vi arkiverade dessa och kallade det för en dag.

Några feature flags var svårare att ta bort eftersom de var utspridda i hela kodbasen och krävde flera utvecklare från olika produktteam för att tas bort. Det tog längre tid än en dag och flera kodgranskningar att ta bort dessa.

Men majoriteten av flaggorna kunde tas bort på ett enkelt och snyggt sätt.

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

Framtidsplaner för feature flags

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

Utgångskriteriet är ett villkor som kvalificerar feature flags för att tas bort. Om en flagga till exempel har rullats ut till allmänheten till 100 % och inga större buggar har rapporterats kan den tas bort om 30 dagar (utgångsdatumet).

Vi ställer in dessa utgångskriterier när vi skriver kriterier för funktionsacceptans, som en överenskommelse mellan:

• Utvecklare: Ingenjören som implementerar feature flags.
• Product Owner: Projektledaren som beslutar om strategin för utrullning av funktioner, skriver de första borttagningskriterierna och kommunicerar funktionen till kunderna.
• QA-team: Revisorer som säkerställer att policyn har utförts korrekt.

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

1. QA-teamet kontrollerar dashboarden Features i Optimizely för att identifiera alla flaggor som har uppfyllt sina utgångskriterier.
2. Flaggor vars utgångsdatum infaller före nästa dag för borttagning av feature flags listas i ett nytt Jira-epik.
3. QA taggar den utvecklare som implementerade flaggan och bjuder in dem till nästa Feature Flag Removal Day-evenemang.
4. På Feature Flag Removal Day samlas utvecklare för att ta bort sina feature flags och arkivera dem i Optimizely Features dashboard.

Sammanfattningsvis

Att avsätta en särskild dag en gång i månaden hjälper till att bygga upp en praxis för att granska varje feature flags i kodbasen med jämna mellanrum för att säkerställa att endast rätt flaggor är live. Detta har gett vårt teknikteam bättre insyn i antalet flaggor som är på väg och hjälper oss att mäta pågående arbete (WIP) som en del av vår agila produkthanterings- och utvecklingsprocess. Genom att aktivt granska våra feature flags på Feature Flag Removal Day säkerställer vi att Optimizely kan släppa produkter snabbt och säkert, samtidigt som kodbasen hålls säker och ren.

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