Hvordan håndtere utdaterte feature flags

Å ikke rydde opp i feature flags kan introdusere risiko i kodebasen din. Lær hvordan en Feature Flag Removal Day kan føre til bedre feature management. Feature flags (også kalt feature toggles) er en gullstandard innen smidig programvareutvikling og kontinuerlig integrasjon av god grunn: de hjelper team med å levere nye funksjoner til kunder på en trygg måte, og med bedre

Å ikke rydde opp i feature flags kan introdusere risiko i kodebasen din. Lær hvordan en Feature Flag Removal Day kan føre til bedre feature management.

Feature flags (også kalt feature toggles) er en gullstandard innen smidig programvareutvikling og kontinuerlig integrasjon av god grunn: de hjelper team med å levere nye funksjoner til kunder på en trygg måte, og med bedre kontroll. Hvis du noen gang har trengt å validere ny funksjonalitet med sluttbrukere, raskt rulle tilbake en endring eller kjøre en A/B-test på en funksjon, er du kanskje også en fan av feature flags. De hjelper med å avrisikere funksjonsutgivelser og kodedistribusjon.

Men som DevOps-ingeniør kan feature flag-håndtering også gi deg hodebry. Når de håndteres dårlig, kan du ende opp med en kodebase oversådd med gamle, glemte feature flags som faktisk introduserer risiko.

En Feature Flag Removal Day er en enkel, effektiv måte å håndtere feature flags på ansvarlig vis.

En feature flag hvis jobb er fullført bør fjernes

Feature flagging lar deg rulle ut kode raskt og trygt. Men når eksperimentet ditt er fullført eller utrullingen er fullstendig distribuert uten mulighet for tilbakerulling, bør en ingeniør fjerne det som en beste praksis for feature flags.

Å ikke gjøre det åpner for muligheten til å eksponere kundene dine for feil funksjon eller for funksjonalitet som ødelegger kodebasen.

Når det er sagt, kan det være vanskelig å prioritere å håndtere feature flags, og eierskapet er ikke alltid tydelig. Du kan sette utløpsdatoer for feature flags-ene dine, men utviklere kan bli oversvømt av andre prosjekter, forlate teamet eller bare trenge gjentatte, vennlige dytt for å prioritere fjerning. Feature Flag Removal Day kan hjelpe deg med å skjære gjennom alt dette.

Hvorfor en Feature Flag Removal Day?

Feature Flag Removal Day er én dag hver måned der utviklere svermer sammen for å fjerne feature flags som har fullført jobben sin. Økten varer vanligvis 4-6 timer — vi bestiller donuts for å holde energien høy! Hos Optimizely kommer noen squads sammen for å fjerne flags som en gruppe; andre tildeler en enkelt utvikler ansvaret for oppgaven.

Målet er ikke nødvendigvis å få fjernet alle flags i løpet av økten. Vi bruker tiden på å revidere utløpte feature flags, sjekke at exit-kriteriene er oppfylt og tildele eiere.

Å utpeke en bestemt dag gir utviklere et fast tidspunkt for å sverme sammen og hjelpe til med å godkjenne Pull Request-endringene for å fjerne feature flags-ene sine.

Den har også følgende fordeler:

En menneskelig sjekk: Du kan bygge inn en menneskelig sjekk med Product Owner for å sikre at hvert flag på listen faktisk bør fjernes.
Sprer hygiene-praksis for feature flags: Å la for mange flags ligge i kodebasen din kan skape teknisk gjeld og gjøre kodebasen skjør. En godt omtalt dag kan hjelpe deg med å gjøre hele organisasjonen din oppmerksom på denne risikoen. Å takle det jevnlig bør bli en del av kulturen i utviklingsteamene dine.
Lettvekts, pålitelig prosess: Fjern frem-og-tilbake-debattene om hvert flag som bør fjernes ved å etablere en standardpraksis og en fast syklus. Hos Optimizely hjelper dette oss med å unngå bekymringen for at feature flags fra tidligere ansatte kan komme tilbake og hjemsøke oss.
Tydelig, tidsavgrenset eierskap: I stedet for å la utviklerne dine eie en bestemt feature flag for alltid, la prosessen håndtere det. På Feature Flag Removal Day tildeler du en utvikler ansvaret for å fjerne det flagget — saken er avsluttet.
Transparens: Gi hele engineering-organisasjonen din beskjed om at visse feature toggles blir fjernet. Dette reduserer sjansen for at et flag som er i bruk av ett team kan bli fjernet av et annet.
Effektiv bruk av utviklernes tid: Sett av en bestemt tid for utviklerne dine til å jobbe med å fjerne feature flags-ene sine. Deretter kan de gå tilbake til sin ordinært planlagte programmering.

Hvilke flags bør fjernes?

Målet er å fjerne alle feature flags som ikke lenger er aktivt i bruk som del av et eksperiment eller en utrulling.

På vår første Feature Flag Removal Day hos Optimizely evaluerte vi hvert eneste flag som passet følgende kriterier:

Flags som ble opprettet før 2019
Flags som ikke har blitt oppdatert siden 2019
Flags som ikke har en bestemt målgruppe knyttet til seg, noe som betyr at de er eksponert for alle
Flags som er rullet ut til 100 % av brukerbasen og 100 % i produksjonsmiljøet

Vi identifiserte 11 flags som matchet disse kriteriene.

Vi snakket med Product Owner for hver funksjon for å sikre at de kunne fjernes. Vi fant to som ikke burde fjernes (det ene var en kill switch, det andre opprettholdt en eldre funksjon for visse kunder). Vi oppdaterte disse flaggene med et exit-kriterium og lot utløpsdatoen stå tom.

Vi undersøkte de resterende ni.

Hva vi fant

Noe av koden var allerede fjernet, men flaggene var fortsatt oppført i dashbordet til feature flagging-systemet vårt. Disse arkiverte vi og lot det være med det.

Noen få feature flags var vanskeligere å fjerne fordi de var distribuert gjennom hele kodebasen og krevde flere utviklere fra ulike produktteam for å fjernes. Disse tok lengre tid enn en dag og flere code reviews å fjerne.

Men flertallet av flaggene ble enkelt og rent fjernet.

Bonus: Praksisen med å fjerne flags ga utviklere et annet perspektiv på beste praksis for å implementere dem. Å plassere dem høyere i kodebasen og ta dem ut tidligere gjør dem lettere å rive ut senere.

Fremtidsplaner for feature flags

Beste praksis-en vår for feature flags inkluderer nå et exit-kriterium og en utløpsdato. Disse markørene hjelper oss med å håndtere hvordan og når vi fjerner flaggene våre.

Exit-kriteriet er en betingelse som kvalifiserer feature flagget for fjerning. Hvis et flag for eksempel er rullet ut til offentligheten på 100 % og ingen større bugs er rapportert, kan det fjernes om 30 dager (utløpsdatoen).

Vi setter dette exit-kriteriet når vi skriver akseptkriteriene for funksjonen, som en avtale mellom:

Utvikler: Ingeniøren som implementerer feature flagget.
Product owner: prosjektlederen som bestemmer funksjonens utrullingsstrategi, skriver de innledende fjerningskriteriene og kommuniserer funksjonen til kunder.
QA-team: Revisorer som sikrer at retningslinjen ble utført korrekt.

Fjerningsprosessen vår ser slik ut:

QA-teamet sjekker Features-dashbordet i Optimizely for å identifisere alle flags som har oppfylt exit-kriteriene sine.
Flags hvis utløpsdato faller før neste Feature Flag Removal Day, listes opp i et nytt Jira-epic.
QA tagger utvikleren som implementerte flagget og inviterer dem til neste Feature Flag Removal Day-arrangement.
På Feature Flag Removal Day samles utviklere for å sverme på å fjerne feature flags-ene sine og arkivere dem i Optimizely Features-dashbordet.

Avslutningsvis

Å sette av en dedikert dag én gang i måneden hjelper med å bygge en praksis for å gjennomgå hver feature flag i kodebasen med jevne mellomrom for å sikre at bare de riktige flaggene er live. Dette har gitt engineering-teamet vårt bedre innsyn i antall flags i omløp, og hjelper oss med å måle work in progress (WIP) som del av vår smidige produktledelses- og utviklingsprosess. Ved aktivt å revidere feature flags-ene våre på Feature Flag Removal Day sikrer vi at Optimizely trygt og raskt kan utgi produkt, samtidig som vi holder kodebasen trygg og ren.

Hvis du vil komme i gang med feature management, kan du sjekke ut Optimizely gratis feature flagging for ubegrensede feature flags og kontrollerte utrullinger.