Feature flags vs blågrön driftsättning: Mindre risk och mer kontroll

En snabb genomgång: blågrön driftsättning innebär att användartrafiken omdirigeras till en annan uppsättning servrar som driftar din uppdaterade applikation. Medan feature flags är kodbaserade och gör det möjligt för användare att se en ny uppdatering genom att göra ändringar på applikationsnivå.

Det här blogginlägget ger en översikt över hur feature flags löser liknande utmaningar som blågrön driftsättning, men med mer kontroll och mindre tidsåtgång. Låt oss ta en titt:

Ett trubbigt verktyg: Blågrön driftsättning

I en blågrön driftsättning utser du en del av dina servrar till att drifta en ny version av din applikation och en annan del av dina servrar till att drifta den tidigare versionen av din applikation. I diagrammet nedan har den blå gruppen servrar den aktuella versionen, medan den gröna gruppen driftar den nya versionen. För att exponera användarna för uppdateringen måste du samordna med driftteamet för att flytta trafiken via lastbalanseraren (även känd som trafikroutern).

Om du gör en release som uppdaterar flera funktioner och du upptäcker en bugg i en av dem kan du enkelt återgå till den tidigare versionen genom att flytta trafiken tillbaka till den tidigare versionen eller den "blå gruppen" av servrar. Blågröna driftsättningar är dock en trubbig lösning på det här sättet eftersom de inte ger kontroll på funktionsnivå. Du måste rulla tillbaka hela uppdateringen för att stänga av bara en funktion.

För- och nackdelar med blågrön driftsättning

• Fördelar: Återställer enkelt en release genom att rulla tillbaka trafiken till en blå miljö
• Fördelar: Kräver inte att ytterligare kod läggs till i din applikation
• Nackdelar: Rullar tillbaka hela utgåvan istället för bara den buggiga funktionen
• Con: Aktiverar inte granularitet på funktionsnivå, bara ändringar på release-nivå
• Nackdel: Delar upp trafiken på servernivå och svårt att bevilja eller begränsa åtkomst till specifika användare
• Nackdel: Kräver ofta att utvecklare och drift samordnar åtkomst till infrastruktur
• Nackdel: Kan vara långsammare att växla över eftersom lastbalanserare kräver att alla anslutningar töms

En exakt lösning: Distributioner med feature flags

Med feature flags (även kända som funktionsväxlingar) har varje funktion i din programuppdatering sin egen flagga eller funktionsväxling som kan kontrolleras oberoende av den fullständiga versionen. Med en feature flag-tjänst som Optimizely Rollouts kan du skapa flaggorna i feature flag-plattformens användargränssnitt och sedan linda in nya funktioner eller kodvägar i feature flag-koden.

Den här gången, om du märker en bugg i en av dina funktioner, behöver du inte rulla tillbaka hela utgåvan. Du kan helt enkelt stänga av den felaktiga funktionen genom att stänga av funktionen i din dashboard för funktionshantering utan att behöva distribuera kod. På så sätt ger feature flags mer kontroll, är mer lyhörda och hjälper till att spara ingenjörstid jämfört med blågrön driftsättning, som kräver samarbete mellan olika team och underhåll av flera uppsättningar versioner på dina servrar.

För- och nackdelar med distributioner med feature flags

• Fördelar: Enkelt att stänga av en enda buggig funktion
• Fördelar: Möjliggör granularitet på funktionsnivå
• Pro: Kan enkelt ge åtkomst till funktioner till enskilda användare, specifika målgrupper eller procentandelar av dina användare
• Pro: Programvaruingenjörer kan göra ändringar utan att involvera IT/DevOps
• Nackdel: Kräver att ytterligare kod läggs till i applikationen och kan skapa teknisk skuld om du inte har en bra metod för att ta bort befintliga flaggor

Rulla ut en uppdatering till endast en delmängd av användarna

Styrkan med att använda feature flags för att släppa funktioner blir ännu tydligare när man tänker på canary releases eller släpper funktioner till en minimal delmängd av din användarbas innan du rullar ut till alla. När du rullar ut en ny release med funktionsuppdateringar vill du sannolikt testköra ändringarna med en liten grupp för att se till att allt fungerar korrekt. Inom programvaruutveckling kallas detta canary testing/deployments eller iscensatta/fasade utrullningar.

Canary testing gör det möjligt att släppa ny kod eller nya funktioner till en liten grupp användare för att verifiera eventuella problem med koden innan den släpps till en större publik. Genom att begränsa releasen till en utvald målgrupp kan du minimera spridningsradien för nya releaser, och teamen kan validera funktionalitet och prestanda innan de rullar ut till alla användare. Det här tillvägagångssättet hjälper också till att upptäcka problem som bara blev synliga när de flyttades från utvecklarmiljöer eller stagingmiljöer till produktion.

Det är möjligt att utföra canary testing genom både blågrön driftsättning och feature flags, men det finns samma utmaningar med att styra trafiken på servernivå.

Canary testing genom blågrön driftsättning: Istället för att styra all trafik från den blå servergruppen som driftar den aktuella versionen av applikationen till den gröna servergruppen kan du flytta bara en procentandel till den nya versionen. Men du har fortfarande inte kontroll på funktionsnivå och måste rulla tillbaka hela releasen om en funktion inte fungerar som den ska. Om du vill ha mer kontroll över vilka kunder som får tillgång till en funktion är det dessutom komplicerat att definiera regler på servernivå.

Canary testing genom distributioner med feature flags: Med feature flags kan du utföra en canary testing med varje funktion som har en on/off-omkopplare genom att välja den del av trafiken som du vill exponera för en viss funktion. Om en viss funktion har en bugg kan du helt enkelt stänga av den istället för att återgå till den tidigare versionen. Du kan också använda målgruppsinriktning för att aktivera funktioner för specifika kunder eller segment av kunder (t.ex. bara kunder på gratisnivån).

Rekapitulation

• Feature flags ger en mer detaljerad och lättanvänd lösning för att minska risken vid lansering av nya funktioner
• Feature flags gör det möjligt för programvaruutvecklingsteam att hantera sina releaser och minska behovet av driftstöd
• Feature flags kan användas för att köra canary testing på användarnivå, vilket ger mer kontroll än på servernivå

Om du vill komma igång med feature flags kan du kolla in vår kostnadsfria lösning: Optimizely Rollouts.