Vad är progressive delivery? Canary, blue-green och flaggor

Vad är progressive delivery? Det är ett sätt att släppa ut mjukvara där en ändring når produktion i små, kontrollerade steg, och där varje steg kontrolleras mot verkliga mätvärden innan nästa börjar. Om siffrorna går åt fel stoppas releasen eller rullas tillbaka av sig själv. Du satsar inte längre hela användarbasen på en enda deploy.

Du känner troligen igen situationen. En pull request är godkänd, CI är grön, deployen går ut en tisdag eftermiddag, och tjugo minuter senare frågar någon i Slack varför checkout-latensen har fördubblats. Progressive delivery finns för att göra det samtalet kortare, och för att göra att det drabbar 5 procent av trafiken i stället för 100 procent.

Vad förändrar progressive delivery egentligen?

Klassisk continuous delivery besvarar en fråga: kan vi leverera det här säkert till produktion? Progressive delivery lägger till en andra fråga: vem ser det först, och vad säger oss att stanna?

Kärnan är att skilja på att deploya och att släppa ut. Att deploya betyder att ny kod körs på servrarna. Att släppa ut betyder att användare exponeras för den. När de två är frikopplade kan du deploya en onsdag klockan 14 och släppa ut i din egen takt, till en vald målgrupp, med en väg tillbaka.

De flesta källor du läser är överens om tre byggstenar: gradvis trafikomkoppling (canary), parallella miljöer (blue-green) och feature flags. De är inte rivaler. Mogna team använder alla tre på olika nivåer.

Canary-releaser: hur mycket trafik, och vem bestämmer?

En canary-release skickar en liten andel trafik, säg 5 procent, till den nya versionen medan resten ligger kvar på den gamla. Om felfrekvens, latens och mättnad håller sig inom dina gränser växer andelen: 5, 25, 50, 100 procent. Om de inte gör det går trafiken tillbaka.

Haken är att finmaskiga uppdelningar kräver något som kan dela trafik. Argo Rollouts-dokumentationen beskriver att exakta canary-procent kräver en trafikhanterare, till exempel ett service mesh eller en ingress-controller. Utan en sådan får du bara grov styrning baserad på antalet replikor, så "5 procent" kan i praktiken betyda "en pod av tjugo".

Så här ser en stegvis canary ut i ett Argo Rollouts-manifest. Den är kort med flit.

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 10m }   # watch dashboards or run analysis
      - setWeight: 25
      - pause: { duration: 10m }
      - setWeight: 100

Hoppa över canary om din tjänst har så lite trafik att 5 procent är en handfull anrop per timme. Du kommer att vänta för evigt på en signal, eller ännu värre, tolka brus som trygghet. För tjänster med låg trafik är feature flags riktade mot interna användare en bättre första grind.

Blue-green-deployer: när är en komplett andra miljö värd det?

Blue-green kör två kompletta produktionsmiljöer. Blue betjänar användare. Green får den nya versionen och testas medan den är inaktiv. När du är nöjd byter trafiken från den ena till den andra.

Enligt Argo Rollouts-dokumentationen sker bytet på en gång: den gamla versionen behåller all produktionstrafik tills den nya är verifierad, och först då går omfördelningen från 0 till 100 procent. Det är styrkan och svagheten. Rollback är en enda omkoppling tillbaka, vilket är snabbt. Men testet sker innan riktiga användare kommer, och kostnaden är dubbel infrastruktur medan båda sidor körs.

Det är värt det om du driftsätter en tillståndsbärande eller kritisk tjänst där en delvis utrullning skulle skapa förvirring, till exempel en betalningsväg där två versioner aldrig får hantera en förfrågan var. Hoppa över det om din databasmigrering inte kan köras mot båda versionerna samtidigt, för då är "omedelbar rollback" en fiktion.

Var passar feature flags in?

Canary och blue-green fungerar på infrastrukturnivå. Feature flags fungerar inne i applikationen. En flagga omsluter en kodväg i ett villkor som du kan ändra under körning, utan att deploya om.

Det gör flaggor till det mest finmaskiga verktyget i lådan. Du kan visa en funktion för de anställda, sedan för 1 procent av kontona, sedan för ett kundsegment, och stänga av den på några sekunder om den beter sig fel. Vissa team ser flaggor som en teknik bland flera andra, andra kallar dem möjliggöraren för hela metoden. I praktiken håller den andra synen: så snart du vill släppa ut efter målgrupp i stället för efter server behöver du en flagga.

Flaggor har dock en egen kostnad. Varje flagga är en förgrening som dina tester måste täcka och en städuppgift som någon måste stänga. Om du vill ha den längre versionen har vi gått igenom mekaniken och skulden i vad en feature flag är. Behandla varje flagga som kortlivad som standard, med en ägare och ett datum för borttagning.

Verktyg som LaunchDarkly och Statsig säljer hanteringslagret: målgruppsregler, granskningslogg, stegvisa procentuella utrullningar och experiment.

Vad gör en utrullning progressiv i stället för bara långsam?

Automation. En utrullning som pausar i tio minuter medan en människa tittar på en dashboard är en långsam deploy. Den blir progressive delivery när en maskin kontrollerar mätvärdena och fattar beslutet.

Mönstret är detsamma överallt:

1. Definiera signalerna före releasen: felfrekvens, p95-latens och ett affärsmått, till exempel slutförda köp i kassan.

2. Definiera trösklar som betyder "stopp", skrivna i konfigurationen och inte i någons huvud.

3. Låt controllern befordra, pausa eller rulla tillbaka utifrån signalerna.

Argo Rollouts integrerar med mätleverantörer så att en utrullning kan befordras eller avbrytas automatiskt beroende på om kontrollerna går igenom. En av källorna vi granskade formulerar det kort: progressive delivery utan automatisk rollback är bara långsam deployment. Vi håller med.

Vilka mätvärden ska styra en utrullning?

Håll det till en liten uppsättning. Tre eller fyra signaler som du redan litar på slår tjugo som du aldrig har larmat på.

En användbar startuppsättning: andelen HTTP 5xx för canary jämfört med baslinjen, p95-latens för canary jämfört med baslinjen, mättnad (CPU, minne, köns djup) och ett produktmått. Jämför canary mot baslinjen i samma ögonblick, inte mot "förra veckan", eftersom trafikmönster förändras.

Här slutar din observability-stack att vara något trevligt att ha. Om du inte kan dela upp mätvärden per version eller per flaggvariant kan du inte skilja canary från baslinjen, och hela metoden faller. Vår genomgång av vad observability är visar hur man kommer dit.

Hur hänger progressive delivery ihop med trunk-based development?

De passar bra ihop. Trunk-based development håller grenarna korta och slår ihop små ändringar ofta. Risken är att oavslutat eller otestat arbete når main oftare. Progressive delivery är det som gör det säkert: koden landar i trunk, levereras bakom en flagga och släpps ut gradvis.

Små satsningar i kombination med gradvis exponering gör också felsökningen billigare. När en canary faller är listan över misstänkta en ändring, inte fyrtio. Den som har bisectat en vecka med sammanslagna commits klockan 23 vet vad det är värt.

Vad är ett realistiskt första steg för ett team på 10 till 30 utvecklare?

Börja inte med att installera ett service mesh. Börja med det minsta som ger dig en stoppknapp.

• Vecka 1: lägg en riskfylld funktion bakom en flagga och släpp ut den till ditt eget team först.

• Vecka 2: lägg till dashboards per version för felfrekvens och latens. Om dina verktyg inte kan dela upp per version, fixa det först.

• Vecka 3 och framåt: flytta en tillståndslös tjänst till en canary-controller med två eller tre steg och automatisk avbrytning vid felfrekvens.

Mät i timmar, inte i en "känsla av trygghet". Räkna hur många incidenter som begränsades till en liten andel användare, och hur lång tid rollback tog. De två talen säger om det fungerar för ditt team.

Var brukar progressiva utrullningar gå sönder?

På tre ställen, och inget av dem är controllern.

Databasmigreringar. En canary innebär att två versioner av koden träffar samma databas samtidigt. Om version N+1 tar bort eller byter namn på en kolumn som version N fortfarande läser, tar canary ner baslinjen. Den tråkiga lösningen är expand and contract: lägg till den nya kolumnen först, släpp kod som skriver till båda, fyll på data i efterhand, byt läsningar och ta bort den gamla kolumnen först senare.

Sticky sessions och cacher. Om en användare hoppar mellan gammal och ny version vid varje förfrågan får du buggar som ingen kan återskapa. Fäst användare vid en variant under utrullningen, med cookie, konto-id eller flaggutvärdering.

Mätvärden som släpar. Ett konverteringsmått som uppdateras varje timme kan inte styra ett canary-steg på tio minuter. Styr på snabba signaler (fel, latens) under utrullningen, och granska det långsamma affärsmåttet innan du går från 50 till 100 procent.

Hur håller du koll på vad som är live i repot?

Progressive delivery sprider en release över konfigurationsfiler, flaggdefinitioner, utrullningsmanifest och dashboards. Efter några månader blir frågan "vilken flagga styr den nya faktureringsvägen, och vem äger den?" den vanliga rutinen: grep, blame och sedan fråga någon.

Det är ett kodläsningsproblem, inte ett verktygsproblem. Att söka i repot på flaggnyckeln och följa varje referens till dess anropsställe är det snabbaste sättet att hitta döda flaggor och halvfärdiga utrullningar. Ett verktyg som svarar på "var utvärderas den här flaggan och vad händer när den är av?" utifrån din faktiska kod sparar mer tid här än ytterligare en dashboard.

Det vi skulle hoppa över

Hoppa över blue-green för allt om din infrastrukturfaktura redan är ett samtalsämne. Hoppa över canaries för tjänster med nästan ingen trafik. Hoppa över rollout-verktyg som ingen i teamet kan felsöka klockan tre på natten.

Det verkliga problemet är inte vilken strategi du väljer. Det är gapet mellan att leverera kod och att veta vad den gör i produktion. Progressive delivery krymper det gapet en trafikskiva i taget, och den första skivan är den som spelar roll: gör den liten, gör den observerbar och ge den en avstängningsknapp.