Vad är en feature flag? Enkel guide för soloutvecklare

Vad är en feature flag? Ett if-villkor vars svar ligger utanför din kod. Du skeppar den nya kodvägen avstängd och slår på den senare genom att ändra ett värde i en konfigfil, en databasrad eller en flaggtjänst, utan någon ny deploy. Det är det som skiljer att deploya kod från att släppa en funktion, och därför är en feature flag den billigaste rollbacken du någonsin kommer att äga.

Jag lärde mig den andra halvan av den meningen på det hårda sättet. Min första flagga var en boolean i en miljövariabel som jag vände på en fredagskväll, och sedan glömde jag att den fanns i elva månader. Ingenting gick sönder. Det är just det som är problemet, och vi kommer till det.

Hur ser en feature flag ut i kod?

Betydligt mindre än leverantörernas startsidor antyder. Skala bort instrumentpanelerna så är en flagga ett uppslag plus en gren:

const flags = { newCheckout: false };

if (flags.newCheckout) {
  return renderNewCheckout(user);
}
return renderOldCheckout(user);

Resten handlar om var flags kommer ifrån och vem som får ändra den. En konstant i filen är en flagga som du ändrar genom att deploya, vilket motverkar hela syftet. En miljövariabel ändras först vid omstart. En databasrad ändras på några sekunder. En hostad tjänst gör det också, och ger dessutom träffsäkring per användare, ett gränssnitt och en ändringslogg.

Det som skaver i praktiken är att koden är trivial men livscykeln inte. Två grenar i produktion betyder två beteenden att testa och två spår att felsöka klockan två på natten, och en av dem är dömd att ruttna.

Vilka fyra typer av feature flags finns, och vilken behöver du först?

Martin Fowlers genomgång av feature toggles är fortfarande det renaste sättet att sortera dem. Den användbara axeln är hur länge varje typ ska leva.

Release-flaggor döljer ofärdigt eller riskfyllt arbete. De ska leva en vecka eller två och sedan tas bort. Det är den du behöver först.

Ops-flaggor fungerar som nödbromsar. Du omsluter en tung eller ömtålig funktion, till exempel en rekommendationsruta eller ett anrop till en tredjepart, så att du kan stänga av den under belastning utan deploy. De flesta är kortlivade, några får stanna för alltid, och det är helt okej.

Experimentflaggor delar upp användare i grupper för A/B-tester. De lever så länge det tar att nå ett statistiskt meningsfullt resultat, alltså timmar till veckor, och de behöver riktig trafik för att betyda något.

Behörighetsflaggor styr funktioner efter plan eller konto, till exempel Pro-nivån eller betagruppen. De kan leva i flera år, och då är de egentligen inte längre flaggor. De är rättigheter, och de förtjänar en ordentlig datamodell.

Om du är soloutvecklare med 40 användare behöver du release-flaggor och kanske en nödbroms. Experimentflaggor på 40 användare ger brus, inte data. Vänta tills du kan namnge måttet och urvalsstorleken.

Vilket problem löser flaggor som branches och deploys inte löser?

Tre saker, och bara tre är värda att bry sig om.

Att skicka ofärdigt arbete säkert. Långlivade branches gör ont eftersom det är ett litet krig att slå ihop dem. En flagga låter dig slå ihop till main varje dag med den nya koden mörklagd. Det är motorn bakom trunk-based development, där alla committar till en gren och flaggorna bär de ofärdiga delarna.

Gradvis utrullning. Slå på funktionen för dig själv, sedan för 1 procent av användarna, sedan 10 procent, sedan alla. Fowler beskriver hur man väljer en canary-grupp på ungefär 1 procent genom att ta användar-ID modulo 100. Om något är fel är skadan begränsad till några få personer istället för hela din bas.

Snabb ångring. Att rulla tillbaka en deploy innebär en build, en pipeline och en del nerv. Att vända en flagga innebär en ändring. En dålig dag är skillnaden minuter av smärta mot en timme.

Inget av detta kräver en leverantör första dagen. Allt det kräver disciplin.

Behöver du LaunchDarkly, eller räcker en JSON-fil?

En JSON-fil eller en databastabell räcker tills något av följande blir sant: en icke-utvecklare behöver kunna vända flaggor, du behöver procentuella utrullningar eller träffsäkring per användare, du behöver en revisionslogg över vem som ändrade vad, eller du kör flera tjänster som läser samma flaggor.

Det här är den ungefärliga stegen jag skulle klättra, i ordning:

1. Konstanter och miljövariabler. Noll kostnad. Bra för den första release-flaggan i ett side project.

2. En tabell flags eller en JSON-fil som du läser vid körning. Tio rader kod, omedelbara ändringar, ingen leverantör. Det här tar ett soloprojekt förvånansvärt långt.

3. En tjänst för flaggor med öppen källkod eller som hostas. När du vill ha träffsäkringsregler, gradvis utrullning och ett gränssnitt som någon annan kan använda.

4. En plattform för företag. När compliance, godkännanden och dussintals ingenjörer kommer in i bilden.

Hostade verktyg täcker steg 3 och 4. LaunchDarkly är branschledaren, med den djupaste träffsäkringen och styrningsfunktionerna, och ett pris som speglar det.

Statsig paketerar flaggor tillsammans med experiment och produktanalys, vilket är vettigt om du tänker mäta vad flaggan gjorde och inte bara vända den.

Hoppa över båda om hela ditt team är du. En tabell med tre kolumner slår en instrumentpanel som du öppnar två gånger per kvartal. Välj en tjänst först när den manuella versionen har kostat dig något konkret, som en nattlig ändring i produktionskonfigurationen som du senare ångrade.

En försäkring som är värd att känna till: OpenFeature är ett CNCF-projekt i inkubation som definierar ett leverantörsneutralt API för att utvärdera flaggor, med SDK:er för bland annat Node.js, Python, Go, Java, .NET och webbklienter. Du kodar mot standardgränssnittet och byter leverantör under huven. Om du misstänker att du kommer att växa ur din första uppsättning gör OpenFeature flytten till en konfigändring.

Hur lägger du din första flagga utan att det blir en röra?

Börja med en enda release-flagga och några grundregler. Det här är versionen jag önskar att jag hade följt.

Namnge den efter funktionen, inte mekanismen. new-checkout-flow berättar vad som går sönder om den är fel. flag_47 berättar ingenting om sex månader.

Standardvärdet är av, och av betyder det gamla beteendet. Konventionen att "av betyder gammalt, på betyder nytt" är det som gör att du kan resonera om systemet under press. Bryter du den blir varje flagga ett pussel.

Utvärdera på ett enda ställe. Fowler kallar lösningen för toggle inversion: istället för att strö if (flags.x) över tjugo filer avgör du en gång, nära systemets kant, och skickar in resultatet. En beslutspunkt betyder ett ställe att ändra och ett ställe att testa.

Skriv borttagningsärendet i samma stund som du skapar flaggan. Lägg det i backloggen med ett datum. Fowler föreslår också utgångsdatum för kortlivade toggles, och till och med tester som failar när en flagga passerat sitt datum. En flagga utan borttagningsärende är ett lån utan återbetalningsplan.

Logga varje utvärdering som spelar roll. När en användare rapporterar en bugg vill du veta vilken sida av flaggan den var på. Om du inte kan svara på det är flaggan en belastning.

Testning är där folk överkonstruerar. Du behöver inte testa varje kombination av flaggor, eftersom de flesta flaggor inte påverkar varandra. Testa den konfiguration du förväntar dig i produktion, testa reservvägen med den nya flaggan av, och kör gärna ett pass med allt påslaget för att fånga drift.

Vad kostar feature flags som ingen nämner?

Varje flagga fördubblar en kodväg. Tio oberoende flaggor ger i teorin 1,024 kombinationer, och även om du aldrig testar dem alla kan du ändå träffa en i produktion som ingen förutsåg.

Den mer smärtsamma kostnaden är döda flaggor. Utrullningen är klar, alla använder det nya beteendet, flaggan står kvar på 100 procent och den gamla grenen ligger kvar i repot som kod ingen vågar ta bort. Sex månader senare vet ingen om det är säkert att stänga av den.

Den kända versionen är Knight Capital i augusti 2012. En gammal flagga som en gång aktiverat en pensionerad handelsfunktion återanvändes för ny kod. En av åtta servrar missade driftsättningen och körde kvar den gamla koden. På 45 minuter förlorade företaget ungefär $440 miljoner, enligt bolagets egen kvartalsrapport. Senare rapporter lägger förlusten närmare $460 miljoner. Det är ett handelsbolag med riktiga pengar och riktiga ingenjörer, så jag tänker inte påstå att ditt side project är säkrare. Lärdomen skalar ner bra: återanvänd aldrig ett flaggnamn, och ta bort döda flaggor innan de blir arkeologi.

Fowlers synsätt är det jag håller fast vid: behandla flaggor som lager med en bärkostnad. Vissa team begränsar antalet levande flaggor och kräver att man tar bort en innan man lägger till en ny. För en soloutvecklare räcker ett hårt tak på fem.

När ska du hoppa över feature flags helt?

Oftare än verktygsleverantörerna medger.

Hoppa över dem när funktionen är liten, ändringen är enkel att återställa i git och din deploy tar två minuter. En flagga lägger till en gren, en konfigkälla och något att glömma. Om en revert går snabbare än att vända en flagga är flaggan bara teater.

Hoppa över dem när du inte har några användare än. En gradvis utrullning till noll personer är bara en fördröjning. Skicka, titta i loggarna, fixa.

Hoppa över dem för databasmigreringar som inte kan ångras med en omkopplare. En flagga kan dölja en ny kolumn i gränssnittet men den kan inte återskapa en tabell som släppts. Schemaändringar behöver en egen expand-and-contract-plan, med eller utan flaggor.

Det är värt det när ändringen rör betalningar eller autentisering, när du vill slå ihop dagligen med ofärdigt arbete, eller när ett beroende från tredje part kan falla och du vill ha en nödbroms.

Vad behöver du bevaka när en flagga är live?

En flagga styr exponeringen, och exponering hjälper bara om du kan se vad som händer sedan. Att slå på en funktion för 10 procent av användarna utan att titta på felfrekvens och latens är ett myntkast med extra steg.

Innan första utrullningen ska du kunna svara på tre frågor på under en minut: har felen ökat i den flaggade gruppen, har latensen blivit sämre, och har något nedströms ändrats? Uptime-övervakning och loggsökning täcker det mesta för en liten produkt. Ett verktyg som Better Stack samlar övervakning, statussidor och loggar på ett ställe, med en gratisnivå.

Så här gör jag nu: en flagga är bara så bra som larmet som hänger på den. Utan larm vrider du på saker i mörkret.

Vad gör vi konkret den här veckan?

Välj en pågående sak som du är rädd att slå ihop. Lägg den bakom en boolean som läses från en tabell eller JSON-fil, med standardvärde av, och slå ihop till main idag. Skriv borttagningsärendet innan du stänger editorn, med ett datum två veckor fram.

Slå sedan på den bara för dig själv och använd den en dag. Håller den, vidga den. Håller den inte, vänd av den, och du har bara förlorat en minut.

Vilken flagga i din kodbas har stått på 100 procent i mer än en månad? Den är din första borttagning.