Utrullingsfasen av programvarelevering spiller en vesentlig rolle i dagens programvareutvikling, enda mer i et skymiljø.
Til tross for det er det også en av de mest undervurderte leveringsfasene. Bedrifter investerer vanligvis ikke nok tid og energi til å gjøre distribusjonen rask, pålitelig, automatisert eller noen av disse.
Mesteparten av tiden ser jeg fortsatt ulike former for manuelle distribusjonsprosedyrer. I bedre tilfeller, i det minste med en godt dokumentert trinnsjekkliste. I verste fall bare tilfeldige planer skapt av improvisasjon i de siste minuttene.
Automatisert distribusjonsprosedyre er alltid et fjernt mål og kort til mellomlang sikt veikart plassholder, men den faktiske veien dit er humpete og uforutsigbar. Men å ha en helautomatisert og pålitelig distribusjonsprosedyre er nøkkelen til betydelige besparelser over tid. Du kan da eliminere innsatsen mesteparten av utviklingsteamet vanligvis bruker for hver produksjonsutgivelse å distribuere.
Canary og Blue-Green distribusjonsstrategier tar alle disse fordelene og legger til flere, høy tilgjengelighet og raske installasjons- og tilbakestillingsprosesser. Gjør det mulig for teamet å slippe enda oftere og uten flere søvnløse netter. La oss ta en titt på hva de har med seg og hvordan de er forskjellige.
Innholdsfortegnelse
Blue-Green Deployment: En oversikt
Kilde: cncf.io
Blue-Green-distribusjon reduserer nedetid og risiko for nye programvareversjoner ved å lage to identiske miljøer: aktiv (blå) og inaktiv (grønn).
Det aktive miljøet er der den gjeldende versjonen av programvaren kjører, og brukerne genererer produksjonstrafikk. Det inaktive miljøet er der den nye versjonen av programvaren distribueres og testes.
Når den nye versjonen er testet og klar, byttes trafikken fra det aktive miljøet til det inaktive miljøet, noe som gjør det til det nye aktive miljøet. Du kan gjenta denne prosessen etter behov.
Les også: Blue-Green Deployment og dens rolle i DevOps forklart
Nøkkelfunksjoner og fordeler
Dette er de spesifikke funksjonene til Blue-Green distribusjonsprosessen:
- To identiske miljøer er identiske fra data- og prosesssynspunkt. Det blå (aktive) miljøet er der produksjonsbrukere kjører sine daglige prosesser. Det grønne (inaktive) miljøet er der den nye distribusjonen er installert og alltid synkronisert med det blå.
- Trafikkbytte som du kan gjøre fra det aktive miljøet til det inaktive miljøet, noe som gjør det til det nye aktive miljøet. Bryteren er øyeblikkelig. All utplasseringen er nå en saga blott. Det er ikke noe nedetidsvindu. Brukere trenger ikke å gjøre noe for å nå det nye miljøet.
- Rask tilbakerulling ved problemer er en konsekvens. Dette sikrer minimal nedetid hvis noe går galt med den nye versjonen av programvaren, og applikasjonen forblir svært tilgjengelig.
- Automatisert testing er et nøkkelaspekt ved Blue-Green-distribusjon. Den sikrer at den nye versjonen av programvaren blir grundig testet før den distribueres til det aktive miljøet.
- Denne distribusjonen er en del av en kontinuerlig leveringspipeline, som til syvende og sist betyr raskere og hyppigere utgivelser av programvare i produksjon. Siden distribusjonen allerede var ferdig og du bare trenger å gjøre selve trafikkbyttet, er det så raskt at du kan gjøre dette hver dag. Forutsatt at du er rask med å teste aktiviteter.
Canary Deployment: En oversikt
Kilde: cncf.io
Canary-distribusjon utfører en gradvis utgivelse av nye funksjoner eller oppdateringer til en liten undergruppe av brukere før den rulles ut til hele brukerbasen.
Denne tilnærmingen innebærer å lage en ny versjon av programvaren og distribuere den til en liten gruppe mens den gamle versjonen kjøres for resten av brukerne. Utviklingsteamet overvåker den nye versjonen nøye for å sikre at den er stabil og fungerer som forventet.
Hvis alt går bra, ruller den nye versjonen ut til flere brukere til den til slutt treffer hele brukerbasen. På denne måten minimerer prosjektteamet risikoen for å introdusere feil eller andre problemer som kan påvirke alle brukere samtidig.
Hensikten er å redusere risikoen for å introdusere nye funksjoner til en stor brukerbase. Overgangen til den nye versjonen gjøres derfor mye smidigere.
Les også: Canary Deployment og dens rolle i DevOps forklart
Nøkkelfunksjoner og fordeler
Dette er de spesifikke egenskapene til Canary-distribusjonsprosessen:
- Distribuer den nye versjonen til en liten undergruppe av brukere først, og rulle den deretter gradvis ut til flere brukere over tid. Du minimerer risikoen for å introdusere feil eller andre problemer som kan påvirke alle brukere samtidig.
- Overvåk den nye versjonen nøye for å sikre at den er stabil og fungerer som forventet. Utviklere kan motta tilbakemelding på den nye versjonen raskere, slik at de kan gjøre nødvendige justeringer før de distribueres til hele brukerbasen.
- Hvis det oppstår problemer, ruller du tilbake distribusjonen til forrige versjon raskt og enkelt. Dette bidrar til å øke tilliten til utviklere og interessenter i distribusjonsprosessen, ettersom det reduserer risikoen for å introdusere problemer som kan påvirke brukeropplevelsen.
- Automatiser distribusjonsprosessen så mye som mulig for å redusere risikoen for menneskelige feil.
Sammendrag: Blue-Green Deployment vs Canary Deployment
FunksjonBlå-grønn DeploymentCanary DeploymentData SyncKonstant datasynkronisering mellom blå og grønne miljøer. Et undersett av brukere eller servere mottar den nye versjonen; resten fortsetter med gjeldende versjon.Aktiveringsprosess Bytt fra aktivt til inaktivt miljø når en ny versjon er klar.Gradvis utrulling til et definert delsett av brukere som aktivt tester nye versjoner.ProduksjonsbrukeropplevelseIngen nedetid i produksjonen; sømløs veksling mellom aktive miljøer. En undergruppe av produksjonsbrukere tester aktivt den nye versjonen; potensielle problemer for denne gruppen.Høy tilgjengelighet vs. tilbakemeldingshastighetPrioritet på høy tilgjengelighet.Prioritet på raskere tilbakemelding og kontrollert utrulling.RisikoreduseringReduksjon av problemmulighet gjennom gradvis utgivelse til en undergruppe av brukere.Testing hovedsakelig i inaktive miljøer; testere fanger kanskje ikke opp alle problemer i den virkelige verden.TesttilnærmingTesting hovedsakelig i inaktive miljøer; Det er ikke sikkert at testere fanger opp alle problemer i den virkelige verden. Produksjonsbrukere fungerer som testere og oppdager problemer i den virkelige verden tidlig. Bemerkelsesverdige brukstilfeller Netflix, Amazon, Etsy, LinkedIn og IBM bruker Blue-Green.Netflix og Google bruker Canary, sammen med automatisert testing og gradvise utrullinger.
Blågrønn distribusjon vs. Canary-utplassering: Funksjoner
Utplassering
Blå-grønn utplassering betyr to miljøer (blått og grønt). Men samtidig er de to miljøene hele tiden synkroniserte når det gjelder data. Dette øker etterspørselen etter permanente datasynkroniseringsprosesser mellom de to miljøene.
Når den nye versjonen er testet og ansett som klar, byttes trafikken fra det aktive miljøet til det inaktive miljøet, noe som gjør det til det nye aktive miljøet.
Du bruker ikke tid på å distribuere ny kode, og det er ingen produksjonsstans involvert. Alle produksjonsbrukere jobber hele tiden på det aktive miljøet, og de legger ikke engang merke til bryteren.
Kilde: aws.amazon.com
Canary-distribusjon innebærer å distribuere en ny versjon av programvaren til et lite undersett av brukere mens de fleste brukere eller servere fortsetter å bruke den gjeldende versjonen. Dette er en gradvis distribusjon i stedet for en full bytte. Testere er, i dette tilfellet, direkte produksjonsbrukere, selv om bare en definert undergruppe av dem. Denne gruppen tester aktivt den nye versjonen med produksjonsprosesser, og når den endelig er stabil, vil den nye versjonen spre seg til resten av brukerne.
Blå-grønn utplassering skal være ditt valg hvis høy tilgjengelighet er prioritet. Du kan favorisere Canary-distribusjon hvis du foretrekker raskere tilbakemelding og en mer kontrollert (men tregere) utrulling.
Redusering av risikoforskjell
Blue-Green-distribusjon reduserer risikoen for utgivelsesfeil ved raskt å bytte til den stabile forrige versjonen. For hver bruker og umiddelbart. Det er åpenbart fortsatt en risiko for at nye funksjoner vil bli forsinket for brukerne i tilfelle tilbakerulling, men i det minste vil ingen av brukerne bli blokkert på grunn av noen kritiske problemer fra den nye utgivelsen.
Risikoreduserende strategi for utplassering av Canary ligger i gradvis reduksjon av problemmulighetene. Siden de nye funksjonene er utgitt til en undergruppe av produksjonsbrukere, bruker de allerede den programvareversjonen en gang før utgivelsen spres til alle brukere. Sannsynligheten er veldig stor for at de første brukerne vil oppdage slike problemer snart.
Testtilnærmingsforskjell
Blue-Green-distribusjon forlater testprosessene utelukkende for det inaktive miljøet. Her kan utviklere, testere og ulike interessenter teste hva de vil. Du kan alltid forvente lignende oppførsel som om testene ville kjøre direkte på det aktive produksjonsmiljøet (siden dataene og konfigurasjonen alltid er synkronisert mellom de to miljøene).
Så testerne dine kjører testprogrammet, og det er fortsatt en mulighet for at de ikke vil fange opp alle problemene de ekte produksjonsbrukerne ville gjort. Imidlertid er det egentlig ikke et problem siden vekslingen mellom inaktive og aktive miljøer alltid er rask. Du kan deretter la utviklere fikse problemet og gjøre byttet på nytt.
Kilde: ibm.com
Canary-distribusjon lar deg bruke produksjonsbrukere som testere. Slike brukere har vanligvis en tendens til å finne flere problemer på kortere tid. De kjører ganske enkelt daglige forretningsprosesser på en fullstendig ende-til-ende måte.
Ikke bare fordi de konstruerte slike testscenarier og tilfeller, men fordi de må gjøre det uansett. Du risikerer at de i gruppen vil ha alvorlige problemer en stund. Men det påvirker ikke flertallet av brukerne, og utviklingsteamet kan konsentrere seg om de mest alvorlige problemene i den virkelige verden med en gang.
Erfarings- og brukssaker
Her er noen av de kjente brukstilfellene der slike distribusjoner allerede kjører vellykket:
- Netflix bruker Blue-Green-distribusjon for å distribuere nye versjoner av strømmetjenesten.
- Amazon og Etsy bruker Blue-Green-distribusjon for å distribuere nye versjoner av deres e-handelsplattform.
- LinkedIn bruker Blue-Green-distribusjon til å distribuere nye versjoner av sin sosiale nettverksplattform.
- IBM bruker Blue-Green-distribusjon til å distribuere nye versjoner av sin skyplattform.
- Netflix bruker også Canary Deployment til å rulle ut endringer i strømmetjenesten. Selskapet bruker en kombinasjon av automatisert testing, funksjonsflagg og A/B-testing for sakte å rulle ut endringer.
- Google bruker Canary Deployment til å implementere endringer i skytjenestene sine. På samme måte bruker selskapet fordelene med automatisert testing, trafikkdeling og inkludering av overvåking til gradvis å rulle ut endringer til en liten undergruppe av brukere før de distribueres til alle brukere.
Beste praksis og fremtidige trender
Automatisering er nøkkelen, og DevOps-pipelines er definitivt fremtiden for distribusjonsprosesser. Dette er helautomatiske prosesser som inneholder trinn som:
- Oppretting eller oppdatering av målmiljøer når det gjelder tjenester, data, brukere eller privilegier.
- Automatisert distribusjon av full-/delta-versjoner av kildekodene direkte fra kodelageret.
- Databaseskjemaoppgradering og dataoppdatering.
- Automatisert testkjøring direkte under distribusjonsaktivitetene.
- Automatiserte tilbakeføringsprosesser i tilfelle en viktig testsak ikke ble fullført.
- Eliminering av eventuelle manuelle intervensjonstrinn til null.
Når du har slike distribusjonsrørledninger, kan du koble til Canary- eller Blue-Green-prosessene eller noe annet du liker. Dette er bare to av eksemplene som allerede har vist seg å fungere godt. Men det er bare filosofiske rammer for å løse de fleste problemene med distribusjonsaktiviteter. Det er ikke engang vanskelig å bytte mellom dem over tid eller bruke en kombinasjon av begge.
Siste ord
Å holde seg til manuelle distribusjonsprosedyrer er synet av umodne utviklingsprosesser eller til og med team. Alternativt kan det avsløre hvor lite fleksibelt og monolittisk det aktuelle selskapet er når det gjelder levering av programvare. I begge tilfeller betyr det mye arbeid å fikse status quo. Så prøv å implementere distribusjonsstrategiene ovenfor for prosjektet ditt.
Deretter kan du sjekke ut hvordan du distribuerer applikasjoner i Kubernetes.