Slik håndterer du utdaterte funksjonsflagg

Hvis du ikke rydder opp i funksjonsflagg, kan det medføre risiko for kodebasen din. Lær hvordan Feature Flag Removal Day kan føre til bedre funksjonshåndtering.

Det er en god grunn til atfunksjonsflagg (også kjent som feature toggles) er en gullstandard for smidig programvareutvikling og kontinuerlig integrasjon: De hjelper teamene med å levere nye funksjoner til kundene på en trygg måte og med bedre kontroll. Hvis du noen gang har hatt behov for å 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 funksjonsflagg. De bidrar til å redusere risikoen ved funksjonsutgivelser og kodedistribusjon.

Men som DevOps-ingeniør kan håndtering av funksjonsflagg også gi deg halsbrann. Når de forvaltes feil, kan du ende opp med en kodebase full av gamle, glemte funksjonsflagg som faktisk medfører risiko.

En dag for fjerning av funksjonsflagg er en enkel og effektiv måte å håndtere funksjonsflagg på en ansvarligmåte .

Et funksjonsflagg som har gjort jobben sin, bør fjernes

Med funksjonsflagging kan du rulle ut kode raskt og trygt. Men når eksperimentet er fullført eller utrullingen er ferdig utrullet uten mulighet for tilbakestilling, bør ingeniøren fjerne det som en beste praksis for funksjonsflagg.

Hvis du ikke gjør det, risikerer du å eksponere kundene dine for feil funksjon eller funksjonalitet som bryter med kodebasen.

Når det er sagt, kan det være vanskelig å prioritere håndteringen av funksjonsflagg, og eierskapet er ikke alltid klart. Du kan angi utløpsdatoer for funksjonsflaggene, men utviklere kan bli overveldet av andre prosjekter, slutte i teamet eller bare trenge gjentatte, milde oppfordringer for å prioritere fjerning. En dag for fjerning av funksjonsflagg kan hjelpe deg med å komme gjennom alt dette.

Hvorfor en dag for fjerning av funksjonsflagg?

Feature Flag Removal Day er en dag i måneden hvor utviklere går sammen for å fjerne funksjonsflagg som har fullført jobben sin. Økten varer vanligvis i 4-6 timer - vi bestiller smultringer for å holde energien oppe! Hos Optimizely samles noen grupper for å fjerne flagg som en gruppe, mens andre utpeker en enkelt utvikler til å ta seg av oppgaven.

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

Ved å utpeke en bestemt dag får utviklerne en fast tid til å samles for å hjelpe til med å godkjenne Pull Request-endringene for å fjerne funksjonsflaggene sine.

Det har også følgende fordeler:

• En menneskelig kontroll: Du kan legge inn en menneskelig kontroll sammen med produkteieren for å sikre at alle flaggene på listen skal fjernes.
• Sosialiserer praksis for funksjonsflagghygiene: For mange flagg i kodebasen kan føre til teknisk gjeld og gjøre kodebasen skjør. En godt annonsert dag kan hjelpe deg med å gjøre hele organisasjonen oppmerksom på denne risikoen. Det bør bli en del av kulturen i utviklingsteamene å ta tak i dette jevnlig.
• En lett og pålitelig prosess: Fjern debattene frem og tilbake om hvert flagg som skal fjernes, ved å etablere en standard praksis og en fast syklus. Hos Optimizely hjelper dette oss med å unngå angsten for at tidligere ansattes funksjonsflagg kan komme tilbake og hjemsøke oss.
• Tydelig, tidsavgrenset eierskap: I stedet for å la utviklerne eie et spesifikt funksjonsflagg for alltid, kan du la prosessen håndtere det. På dagen for fjerning av funksjonsflagg kan du tildele en utvikler ansvaret for å fjerne flagget - saken er avsluttet.
• Åpenhet: Gi hele organisasjonen beskjed om at visse funksjonsflagg blir fjernet. Dette reduserer sjansen for at et flagg som er i bruk av ett team, blir fjernet av et annet.
• Effektiv bruk av utviklernes tid: Sett av et bestemt tidsrom der utviklerne kan jobbe med å fjerne funksjonsflaggene sine. Deretter kan de gå tilbake til den vanlige programmeringen.

Hvilke flagg bør fjernes?

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

På vår første dag for fjerning av funksjonsflagg hos Optimizely vurderte vi hvert eneste flagg som oppfylte følgende kriterier:

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

Vi identifiserte 11 flagg som oppfylte disse kriteriene.

Vi snakket med produkteierne for hver funksjon for å sikre at de kunne fjernes. Vi fant to som ikke burde fjernes (den ene var en "kill switch", og den andre opprettholdt en eldre funksjon for enkelte kunder). Vi oppdaterte disse flaggene med et avslutningskriterium og en tom utløpsdato.

Vi undersøkte de resterende ni.

Det vi fant

Noe av koden var allerede fjernet, men flaggene var fortsatt oppført i dashbordet for funksjonsflaggingssystemet vårt. Vi arkiverte disse og avsluttet arbeidet.

Noen få funksjonsflagg var vanskeligere å fjerne fordi de var spredt utover hele kodebasen og krevde flere utviklere fra ulike produktteam for å bli fjernet. Det tok mer enn én dag og flere kodegjennomganger å fjerne disse.

Men de fleste flaggene ble fjernet enkelt og ryddig.

Bonus: Øvelsen med å fjerne flagg ga utviklerne et annet perspektiv på beste praksis for å implementere dem. Ved å plassere dem høyere opp i kodebasen og fjerne demtidligere, blir de lettere å fjerne senere.

Fremtidige planer for funksjonsflagg

Vår beste praksis for funksjonsflagg inkluderer nå et utløpskriterium og en utløpsdato. Disse markørene hjelper oss med å styre hvordan og når vi fjerner flaggene våre.

Utløpskriteriet er en betingelse som gjør at funksjonsflagget kan fjernes. Hvis et flagg for eksempel har blitt rullet ut til offentligheten 100 % og ingen større feil har blitt rapportert, kan det fjernes om 30 dager (utløpsdatoen).

Vi angir dette utløpskriteriet når vi skriver kriterier for funksjonsaksept, som en avtale mellom:

• Utvikler: Ingeniøren som implementerer funksjonsflagget.
• Produkteier: Prosjektlederen som bestemmer strategien for utrulling av funksjonen, skriver de første kriteriene for fjerning og kommuniserer funksjonen til kundene.
• QA-team: Revisorer som sørger for at retningslinjene utføres på riktig måte.

Fjerningsprosessen vår ser slik ut:

1. QA-teamet sjekker funksjonsoversikten i Optimizely for å identifisere alle flagg som har oppfylt utløpskriteriene.
2. Flagg med utløpsdato før neste dag for fjerning av funksjonsflagg blir oppført i en ny Jira-epikrise.
3. QA tagger utvikleren som har implementert flagget, og inviterer vedkommende til neste Feature Flag Removal Day-arrangement.
4. På Feature Flag Removal Day samles utviklerne for å fjerne funksjonsflaggene sine og arkivere dem i Optimizely Features-dashbordet.

Konklusjon

Ved å sette av en dedikert dag en gang i måneden kan vi bygge opp en praksis med å gjennomgå alle funksjonsflagg i kodebasen med jevne mellomrom for å sikre at bare de riktige flaggene er live. Dette har gitt ingeniørteamet vårt bedre oversikt over antall flagg som er på vei, og hjelper oss med å måle pågående arbeid (WIP) som en del av den smidige produktstyrings- og utviklingsprosessen vår. Ved å aktivt revidere funksjonsflaggene våre på Feature Flag Removal Day sørger vi for at Optimizely kan lansere produkter raskt og trygt, samtidig som vi holder kodebasen trygg og ren.

Hvis du vil komme i gang med funksjonshåndtering, kan du sjekke ut Optimizely gratis funksjonsflagging for ubegrenset funksjonsflagging og kontrollerte utrullinger.