Canary-distribusjon er en teknikk for programvareutvikling og -distribusjon som 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 brukere 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 yter 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 med Canary-distribusjon er å redusere risikoen for å introdusere nye funksjoner til en stor brukerbase. Ved å gradvis rulle ut endringer til brukere, kan utviklere overvåke ytelsen og stabiliteten til den nye versjonen. De gjør nødvendige justeringer før de distribueres til hele brukerbasen. Overgangen til den nye versjonen gjøres derfor mye smidigere.
Innholdsfortegnelse
Nøkkelprinsipper og fordeler
Kilde: martinfowler.com
Nøkkelprinsippene for Canary-distribusjon inkluderer følgende:
Fordelene med Canary-distribusjon i DevOps inkluderer:
Canary-distribusjon basert på konsept og terminologi
Kilde: cncf.io
La oss gå gjennom den typiske livssyklusen til prosessen.
Det hele starter med Canary, det vil si «early adopters» av den nye versjonen av systemet. Parallelt med det er det Baseline-gruppen. Her tilhører alle de andre brukerne som ikke er inne på Canary.
Ettersom Canary-brukerne fortsetter å bruke den nye versjonen, utvides Canary-utrullingen til flere og flere brukere. Dette er Traffic Shifting. Canary-gruppen vokser mens Baseline-gruppen krymper, så systemet utfører gradvis utrulling.
Underveis logger overvåkingsprosessen alle aktivitetene og bruksresultatene og genererer beregninger som utviklere trenger som tilbakemelding. Utviklere reagerer så og fikser det som er nødvendig. Eller de ruller tilbake til grunnlinjen hvis de ikke kan fikse problemene akkurat nå.
Automatiser alle overvåkings- og distribusjonsaktiviteter. Dette gir utviklerne eksklusivt fokus på problemløsning.
Det kan være Canary-gruppen vil finne ut at noen funksjoner i den nye versjonen er dårlige, mens andre er gode. Så utviklerne vil flagge funksjonene som har problemer med å deaktivere dem fra distribusjonsprosesser.
Utviklere holder øye med begge gruppene samtidig – Canary og Baseline. Brukerne genererer A/B-testresultater. Det er oppførselen til det gamle systemet og det nye systemet under de samme forholdene. Men det er også automatiske tester som kjører konstant på den nye versjonen av systemet for å sikre at Canary Group Health Check er stabil.
Hvordan det skiller seg fra de tradisjonelle distribusjonsstrategiene
Etter å ha forstått livssyklusprosessen på høyt nivå, er forskjellene mellom denne og de tradisjonelle distribusjonsprosessene ganske åpenbare.
- Du distribuerer gradvis og med bedre kontroll i stedet for å distribuere alt på en gang til alle og vente på problemene som påvirker hele produksjonen.
- Du begrenser risikoen for nye versjonsfeil kun til Canary-gruppen i motsetning til å utsette hele verden for problemene samtidig.
- Du overvåker den nye versjonen før brukerne har den, i stedet for å overvåke den etter det og investere en del tid og ressurser i hyperomsorgsfasen av utgivelsesprosessen.
- Du kan bestemme deg for tilbakerulling før du distribuerer den nye versjonen fullstendig til produksjon. På den andre siden planlegger du et nytt utgivelsesvindu for å angre produksjonen like etter at produksjonsutgivelsen er fullført.
- Å ha Canary-distribusjon tvinger deg naturligvis til å investere i automatiserte verktøy og prosesser der det er mulig. På den andre siden nedprioriterer det å holde seg til tradisjonelle distribusjonsstrategier naturligvis alle automatiseringsinitiativene til slutten av etterslepet.
CI/CD-rørledninger i Canary Deployment
Kilde: aws.amazon.com
I en typisk CI/CD-pipeline blir endringer automatisk bygget, testet og distribuert til et oppsamlingsmiljø for videre testing før de distribueres til produksjon. Og også, det er et perfekt bruksområde i en Canary-utplassering.
Når endringene har blitt distribuert til oppsamlingsmiljøet og har bestått alle nødvendige tester, vil CI/CD-pipelinen automatisk distribuere kanarieversjonen til en liten undergruppe av brukere i produksjonsmiljøet.
Hvis noe går galt, er det bare å kjøre en annen rørledning for en tilbakeføring. Eller flagg problematiske funksjoner, og det vil aldri vises igjen i distribusjonsprosessen til distribusjonspipelinen. Alt automatisk, og du trenger ikke bry deg om det lenger.
Siden kanarieversjonen er full av automatiserte helsesjekktester, er alle disse naturlig innlemmet i de grunnleggende funksjonene til CI/CD-rørledningene. De er uansett en må-ha-del av enhver god CI/CD Pipeline.
Arbeidsflyt og fasene av Canary-distribusjon
Sammenfattende informasjonen er dette den vanlige arbeidsflyten for en typisk Canary-distribusjon som du kan bruke på prosjektet ditt.
#1. Planlegging og forberedelse
I denne fasen planlegger og forbereder utviklingsteamet for kanari-utplasseringen. Dette inkluderer å identifisere endringene eller oppdateringene som skal gjøres, opprette en ny versjon av programvaren og definere beregningene og helsesjekkene som skal brukes til å overvåke ytelsen til den nye versjonen. Teamet identifiserer også undergruppen av brukere som vil motta den nye versjonen først og definerer utrullingsplanen.
#2. Implementering av trafikkdirigering og overvåking
Den nye versjonen av programvaren distribueres til undergruppen av brukere identifisert i planleggingsfasen. Trafikkruting er implementert for å lede en del av brukertrafikken til den nye versjonen mens den gamle versjonen kjøres for resten av brukerne. Ytelsen og stabiliteten til den nye versjonen overvåkes nøye ved hjelp av beregninger og helsesjekker for å sikre at den fungerer som forventet.
#3. Analysere og evaluere implementeringsytelsen
Ytelsen til den nye versjonen blir analysert og evaluert basert på beregningene og helsesjekkene som er definert i planleggingsfasen. Hvis den nye versjonen gir gode resultater, økes utrullingen gradvis til flere brukere over tid. Hvis det oppstår problemer med den nye versjonen, kan distribusjonen raskt rulles tilbake til forrige versjon.
#4. Fremme eller rulle tilbake distribusjonen
Utviklingsteamet bestemmer om de skal promotere den nye versjonen til hele brukerbasen eller rulle tilbake til forrige versjon. Hvis den nye versjonen fungerer godt og oppfyller de nødvendige kvalitetsstandardene, bør du markedsføre den til hele brukerbasen. Hvis det oppstår problemer med den nye versjonen, ruller du tilbake distribusjonen til forrige versjon raskt og enkelt.
Kilde: aws.amazon.com
Beste praksis og strategier
Når du implementerer Canary Deployment på plattformen din, start med å definere klare mål og hvordan suksessen ser ut på slutten. Du kan hjelpe her med ting som ytelsesberegninger, brukertilbakemeldingskriterier og forretningseffekt.
Opprett et lite undersett av brukere for å teste den nye (Canary) versjonen av programvaren. Den større gruppen i begynnelsen er egentlig ikke en fordel. Du ønsker å være så fleksibel som mulig, spesielt i begynnelsen.
Som nevnt allerede et par ganger, overvåk ytelsen og stabiliteten til den nye versjonen ved hjelp av beregninger og helsesjekker. Reager hver gang du ser noe mistenkelig. Det er bedre å overreagere enn å underreagere når det går til en gradvis utrulling.
Øk gradvis utrullingen av den nye versjonen til flere brukere over tid. Dette sikrer en jevnere overgang til den nye versjonen.
Bruk automatiseringsverktøy og -prosesser der det er mulig for å strømlinjeforme distribusjons- og overvåkingsprosessen. Inkluder dem i CI/CD-pipelines og få dem til å utløse planlagte distribusjonsprosesser automatisk. Dette reduserer risikoen for menneskelige feil og sikrer at distribusjonsprosessen er konsistent og repeterbar.
Implementer funksjonsflagg for å aktivere eller deaktivere spesifikke funksjoner i programvaren. Du vil få kontroll over fremtidige distribusjonsprosesser uten at det er nødvendig å alltid endre eller oppdatere manuelt. Du vil gi utviklere mer fokus på områder som betyr noe – å fikse feilene.
Bruk A/B-testing for å sammenligne ytelsen til to forskjellige versjoner av programvaren. Tildel tilfeldige brukere til den ene eller den andre versjonen. Identifiser hvilken versjon som fungerer best og reager på det med fremtidige utviklingsbeslutninger.
Sørg for at du kan rulle tilbake distribusjonen raskt og når som helst hvis det oppstår problemer med den nye versjonen. Det vil redusere virkningen av eventuelle problemer og gir mulighet for rask gjenoppretting.
Utfordringer og kasusstudier
Det er fortsatt noen utfordringer knyttet til Canary-distribusjon, til tross for dens klare fordeler.
En utfordring med Canary Deployment er nettverksforsinkelse, som kan påvirke ytelsen til den nye versjonen av programvaren. For å møte denne utfordringen kan utviklere bruke verktøy som lastbalansere og innholdsleveringsnettverk for å forbedre nettverksytelsen. Det er ikke bare latens for systemet fra ekstern bruk. Men også latens for interne prosesser som distribusjoner eller CI/CD Pipelines-kjøringer. Disse må fullføres så raskt som mulig. Ellers vil du ha en rekke utviklere i inaktiv tilstand som venter på at rørledningene skal fullføre kjøringen.
En annen utfordring er å sikre datakonsistens mellom den gamle og nye versjonen av programvaren. For å møte denne utfordringen kan utviklere bruke teknikker som databasereplikering og synkronisering for å sikre at data er konsistente på tvers av alle versjoner. Å ha produksjonsbrukere som opererer i både gamle og nye versjoner samtidig øker forventningene om at du vil sørge for at begge versjonene er synkroniserte hele tiden og at brukerne ikke mister produksjonsdata bare fordi de er i Canary/Baseline-gruppen . Dette kan være en veldig utfordrende forventning å møte, så rygg deg selv med solid bakgrunnsprosesser.
Netflix er et velkjent eksempel på et selskap som bruker Canary Deployment til å rulle ut endringer i strømmetjenesten sin. Selskapet bruker en kombinasjon av automatisert testing, funksjonsflagg og A/B-testing for sakte å rulle ut endringer.
Google er et annet eksempel på et selskap som bruker Canary Deployment til å rulle ut 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. Denne tilnærmingen har hjulpet Google med å forbedre kvaliteten og stabiliteten til tjenestene sine.
Siste ord
Som med alle prosesser, tilnærminger eller strategier, er ikke Canary-distribusjon en løsning for alle verdens problemer. Det er tilfeller der det er nesten umulig å implementere på grunn av miljørestriksjoner, folks kunnskap eller en generell mangel på konseptuell forståelse. Jeg
t er mye mer egnet for prosjektene i den nye tiden. Der en smidig tankegang er den bunnsolide grunnleggende egenskapen, er automatisering av hver prosess en utvilsom prioritet, og et maksimalt nivå av pålitelighet er en sterk forventning fra interessentene.
I så fall er Canary-distribusjon på en eller annen måte det neste nivået av smidig utviklingspraksis. Det kan løfte lagene inn i et territorium prosjektet aldri var før.
Deretter kan du sjekke ut skalering og optimalisering av CI/CD.