Implementeringsfasen av mjukvaruleverans spelar en väsentlig roll i dagens mjukvaruutveckling, ännu mer i en molnmiljö.
Trots det är det också en av de mest underskattade leveransfaserna. Företag investerar vanligtvis inte tillräckligt med tid och energi för att göra implementeringen snabb, pålitlig, automatiserad eller någon av dessa.
För det mesta ser jag fortfarande olika former av manuella distributionsprocedurer. I bättre fall, åtminstone med en väl dokumenterad checklista för steg. I värsta fall bara slumpmässiga planer skapade av improvisation de sista minuterna.
Automatiserad distributionsprocedur är alltid ett avlägset mål och platshållare på kort till medellång sikt, men den faktiska vägen dit är ojämn och oförutsägbar. Men att ha en helt automatiserad och pålitlig driftsättningsprocedur är nyckeln till betydande besparingar över tid. Du kan då eliminera den ansträngning som det mesta av utvecklingsteamet vanligtvis lägger ner för varje produktionsversion att distribuera.
Canary och Blue-Green implementeringsstrategier tar alla dessa fördelar och lägger till fler, hög tillgänglighet och snabba installations- och återställningsprocesser. Gör det möjligt för teamet att släppa ännu oftare och utan fler sömnlösa nätter. Låt oss ta en titt på vad de ger och hur de skiljer sig åt.
Innehållsförteckning
Blue-Green Deployment: En översikt
Källa: cncf.io
Blue-Green-distribution minskar driftstopp och risk för nya programvaruversioner genom att skapa två identiska miljöer: aktiv (blå) och inaktiv (grön).
Den aktiva miljön är där den aktuella versionen av programvaran körs och användarna genererar produktionstrafik. Den inaktiva miljön är där den nya versionen av programvaran distribueras och testas.
När den nya versionen är testad och klar växlas trafiken från den aktiva miljön till den inaktiva miljön, vilket gör den till den nya aktiva miljön. Du kan upprepa denna process vid behov.
Läs också: Blue-Green Deployment och dess roll i DevOps Explained
Nyckelfunktioner och fördelar
Dessa är de specifika funktionerna i Blue-Green-distributionsprocessen:
- Två identiska miljöer är identiska ur data- och processsynpunkt. Den blå (aktiva) miljön är där produktionsanvändare kör sina dagliga processer. Den gröna (inaktiva) miljön är där den nya distributionen är installerad och alltid synkroniserad med den blå.
- Trafikväxling som du kan göra från den aktiva miljön till den inaktiva miljön, vilket gör den till den nya aktiva miljön. Växlingen är omedelbar. All utplacering är nu ett minne blott. Det finns inget stilleståndsfönster. Användare behöver inte göra något för att nå den nya miljön.
- Snabb återställning vid problem är en konsekvens. Detta säkerställer minimal driftstopp om något går fel med den nya versionen av programvaran, och applikationen förblir mycket tillgänglig.
- Automatiserad testning är en nyckelaspekt av Blue-Green-distribution. Det säkerställer att den nya versionen av programvaran testas noggrant innan den distribueras till den aktiva miljön.
- Denna distribution är en del av en kontinuerlig leveranspipeline, vilket i slutändan innebär snabbare och mer frekventa releaser av programvara i produktion. Eftersom driftsättningen redan var gjord och du bara behöver göra själva trafikväxlingen går det så snabbt att du kan göra detta varje dag. Förutsatt att du är snabb i testaktiviteter.
Canary Deployment: En översikt
Källa: cncf.io
Canary-distribution kör en gradvis utgivning av nya funktioner eller uppdateringar till en liten delmängd av användare innan den rullas ut till hela användarbasen.
Detta tillvägagångssätt innebär att skapa en ny version av programvaran och distribuera den till en liten grupp samtidigt som den gamla versionen körs för resten av användarna. Utvecklingsteamet övervakar den nya versionen noga för att säkerställa att den är stabil och fungerar som förväntat.
Om allt går bra rullar den nya versionen ut till fler användare tills den så småningom når hela användarbasen. På så sätt minimerar projektteamet risken för att introducera buggar eller andra problem som kan påverka alla användare samtidigt.
Syftet är att minska risken för att introducera nya funktioner till en stor användarbas. Övergången till den nya versionen sker därför mycket smidigare.
Läs också: Canary Deployment och dess roll i DevOps förklaras
Nyckelfunktioner och fördelar
Dessa är de specifika funktionerna i Canary-distributionsprocessen:
- Implementera den nya versionen till en liten del av användare först och rulla den sedan gradvis ut till fler användare med tiden. Du minimerar risken för att introducera buggar eller andra problem som kan påverka alla användare samtidigt.
- Övervaka noga den nya versionen för att säkerställa att den är stabil och fungerar som förväntat. Utvecklare kan få feedback om den nya versionen snabbare, så att de kan göra nödvändiga justeringar innan de distribueras till hela användarbasen.
- Om några problem uppstår återställer du distributionen till den tidigare versionen snabbt och enkelt. Detta bidrar till att öka förtroendet för utvecklare och intressenter i implementeringsprocessen, eftersom det minskar risken för att introducera problem som kan påverka användarupplevelsen.
- Automatisera distributionsprocessen så mycket som möjligt för att minska risken för mänskliga fel.
Sammanfattning: Blue-Green Deployment vs Canary Deployment
FeatureBlue-Green DeploymentCanary DeploymentData SyncKonstant datasynkronisering mellan blå och gröna miljöer. En undergrupp av användare eller servrar får den nya versionen; resten fortsätter med den nuvarande versionen.Aktiveringsprocess Byt från aktiv till inaktiv miljö när en ny version är klar. Gradvis utrullning till en definierad delmängd av användare som aktivt testar nya versioner.Production User ExperienceIngen produktionsstopp; sömlös växling mellan aktiva miljöer. En delmängd av produktionsanvändare testar aktivt den nya versionen; potentiella problem för den här gruppen.Hög tillgänglighet kontra återkopplingshastighet Prioritet på hög tillgänglighet.Prioritet på snabbare återkoppling och kontrollerad utrullning.RiskreduceringReducering av problemmöjlighet genom gradvis utgivning till en undergrupp av användare.Tester främst i inaktiva miljöer; testare kanske inte fångar alla problem i den verkliga världen. Testmetod Testar huvudsakligen i inaktiva miljöer; testare kanske inte upptäcker alla verkliga problem. Produktionsanvändare fungerar som testare och upptäcker problem i verkligheten tidigt. Anmärkningsvärda användningsfall Netflix, Amazon, Etsy, LinkedIn och IBM använder Blue-Green.Netflix och Google använder Canary, tillsammans med automatiserade tester och gradvisa utrullningar.
Blue-Green Deployment vs Canary Deployment: Funktioner
Spridning
Blue-Green distribution betyder två miljöer (blå och grön). Men samtidigt är de två miljöerna ständigt synkroniserade vad gäller data. Detta ökar efterfrågan på permanenta datasynkroniseringsprocesser mellan de två miljöerna.
När den nya versionen är testad och anses vara klar, växlas trafik från den aktiva miljön till den inaktiva miljön, vilket gör den till den nya aktiva miljön.
Du lägger ingen tid på att distribuera ny kod, och det är ingen produktionsstopp inblandad. Alla produktionsanvändare arbetar hela tiden på den för närvarande aktiva miljön, och de märker inte ens bytet.
Källa: aws.amazon.com
Canary-distribution innebär att en ny version av programvaran distribueras till en liten delmängd av användare medan de flesta användare eller servrar fortsätter att använda den nuvarande versionen. Detta är en gradvis implementering snarare än en fullständig switch. Testare är i det här fallet direkta produktionsanvändare, även om endast en definierad delmängd av dem. Denna grupp testar aktivt den nya versionen med produktionsprocesser, och när den äntligen är stabil kommer den nya versionen att spridas till resten av användarna.
Blue-Green distribution ska vara ditt val om hög tillgänglighet är prioritet. Du kan gynna Canary-distribution om du föredrar snabbare feedback och en mer kontrollerad (men långsammare) utbyggnad.
Reducering av riskskillnad
Blue-Green-distribution minskar risken för releasefel genom att snabbt byta till den stabila tidigare versionen. För varje användare och direkt. Uppenbarligen finns det fortfarande en risk att nya funktioner försenas för användarna i händelse av återställning, men åtminstone ingen av användarna kommer att blockeras på grund av några kritiska problem från den nya releasen.
Strategi för riskreducering av kanariefåge-utplacering ligger i en gradvis minskning av möjligheten till problem. Eftersom de nya funktionerna släpps till en undergrupp av produktionsanvändare använder de redan den mjukvaruversionen någon gång innan releasen sprids till alla användare. Sannolikheten är mycket stor att de första användarna kommer att fånga sådana problem snart.
Testmetodens skillnad
Blue-Green distribution lämnar testprocesserna enbart för den inaktiva miljön. Här kan utvecklare, testare och olika intressenter testa vad de vill. Du kan alltid förvänta dig liknande beteende som om testerna skulle köras direkt på den aktiva produktionsmiljön (eftersom data och konfiguration alltid är synkroniserade mellan de två miljöerna).
Så dina testare kör testprogrammet, och det finns fortfarande en möjlighet att de inte kommer att fånga alla problem som verkliga produktionsanvändare skulle göra. Men det är egentligen inget problem eftersom bytet mellan inaktiva och aktiva miljöer alltid går snabbt. Du kan sedan låta utvecklare åtgärda problemet och göra bytet igen.
Källa: ibm.com
Canary-distribution låter dig använda produktionsanvändare som dina testare. Sådana användare tenderar vanligtvis att hitta fler problem på kortare tid. De kör helt enkelt de dagliga affärsprocesserna på ett heltäckande sätt.
Inte bara för att de konstruerade sådana testscenarier och fall utan för att de måste göra det ändå. Du riskerar att de i gruppen har allvarliga problem under en tid. Men det påverkar inte majoriteten av användarna, och utvecklingsteamet kan koncentrera sig på de allvarligaste problemen i verkligheten direkt.
Erfarenhet och användningsfall
Här är några av de kända användningsfallen där sådana distributioner redan körs framgångsrikt:
- Netflix använder Blue-Green-distribution för att distribuera nya versioner av sin streamingtjänst.
- Amazon och Etsy använder Blue-Green-distribution för att distribuera nya versioner av sin e-handelsplattform.
- LinkedIn använder Blue-Green-distribution för att distribuera nya versioner av sin sociala nätverksplattform.
- IBM använder Blue-Green-distribution för att distribuera nya versioner av sin molnplattform.
- Netflix använder också Canary Deployment för att implementera ändringar i sin streamingtjänst. Företaget använder en kombination av automatiserad testning, funktionsflaggor och A/B-testning för att långsamt implementera ändringar.
- Google använder Canary Deployment för att implementera ändringar i sina molntjänster. På samma sätt använder företaget fördelarna med automatiserad testning, trafikuppdelning och övervakningsinkludering för att gradvis implementera ändringar till en liten del av användare innan de distribueras till alla användare.
Bästa praxis och framtida trender
Automatisering är nyckeln, och DevOps pipelines är definitivt framtiden för distributionsprocesser. Dessa är helautomatiska processer som innehåller steg som:
- Skapa eller uppdatering av målmiljöer när det gäller tjänster, data, användare eller privilegier.
- Automatiserad distribution av fullständiga/delta-versioner av källkoderna direkt från kodförrådet.
- Uppgradering av databasschema och datauppdatering.
- Automatiserad testkörning direkt under driftsättningsaktiviteterna.
- Automatiserade återställningsprocesser om något viktigt testfall inte lyckades slutföras.
- Eliminering av eventuella manuella ingreppssteg till noll.
När du väl har sådana distributionspipelines kan du koppla in Canary- eller Blue-Green-processerna eller något annat du vill. Det är bara två av exemplen som redan har visat sig fungera bra. Men det är bara filosofiska ramar för att lösa de flesta problemen med driftsättningsaktiviteter. Det är inte ens svårt att byta mellan dem över tid eller använda en kombination av båda.
Slutord
Att hålla sig till manuella distributionsprocedurer är åsynen av omogna utvecklingsprocesser eller till och med team. Alternativt kan det avslöja hur oflexibelt och monolitiskt det specifika företaget är när det gäller leverans av programvara. I båda fallen innebär det mycket arbete att fixa status quo. Så försök att implementera de strategier som nämns ovan för ditt projekt.
Kolla sedan in hur du distribuerar applikationer i Kubernetes.