Flowchart for software deployment: fra build til produktion

Hvad er flowchart for software deployment: fra build til produktion?

En software deployment-proces er mekanikken i at få ét build-artefakt ud på kørende infrastruktur. Den starter ved et merge og slutter enten med en version, der er fuldt udrullet, eller med et rollback til den forrige. Det gør den bevidst snævrere end release management, som afgør, hvad der hører til i en release, hvornår scope fryses, og om organisationen er klar til at sende af sted. Release management svarer på om og hvad; deployment svarer på hvordan. Indeholder det diagram, I har brug for, en scope-fryse, en UAT-godkendelse og et go/no-go-møde, er det releaseprocessen, I skal bruge. Indeholder det en artefaktversion, et register, en trafikflytning og en rollback-trigger, er I det rigtige sted. Det er heller ikke IT-ændringsstyring: ændringsvinduet og godkendelsen, der åbner det, optræder her som to trin, ikke som emnet, fordi diagrammet forudsætter, at der allerede findes en godkendelsesvej, og viser, hvor deploymentet venter på den.

De fleste deployment-hændelser kan spores tilbage til nogle få utegnede antagelser. Artefaktet bygges igen pr. miljø, så det, der bestod testene, er ikke helt det, der nåede produktion. Staging skred væk fra produktionskonfigurationen for måneder siden, så en grøn smoketest beviser mindre, end folk tror. Udrulningen har ingen defineret trinstørrelse eller modningstid, så al trafikken flyttes på én gang, og det første tegn på problemer er supportkøen. Og rollback-triggeren er et menneske, der kigger på et dashboard, frem for en tærskel, pipelinen selv kan vurdere, hvilket forvandler et hurtigt, kedeligt rollback til en diskussion. Når flowet tegnes som swimlanes, bliver det tydeligt, hvilke af disse trin I har automatiseret, og hvilke der stadig afhænger af, at nogen husker dem.

Denne skabelon er et fungerende deployment-flow på tværs af fem baner (Udvikler, CI/CD-pipeline, QA, Releaseansvarlig og Drift) lagt ud over fem faser fra build til udrulning i produktion. Den tegner de tre løkker, der normalt ikke er dokumenteret: kvalitetsporten, der sender et fejlende build tilbage til udvikleren i stedet for at lade det gå videre, staging-tjekket, der gør det samme, før nogen booker et ændringsvindue, og det automatiske rollback, der sender en overskredet udrulning tilbage til det samme fejlrettelsestrin. Den viser desuden deployment-strategien som en beslutning frem for en antagelse, så blue-green og canary står på diagrammet som to navngivne veje, der mødes igen i en fælles trafikflytning med health checks.

Hvad dette flowchart dækker

I denne skabelon

• Build og version i de første to baner: en udvikler merger til main-branchen, hvorefter CI/CD-pipelinen bygger artefaktet én gang og stempler det med den commit, det kom fra, så alle senere miljøer deployer præcis det samme artefakt
• Kvalitetsporten: pipelinen kører de automatiske tests og scanninger, hvorefter QA ejer beslutningen 'Kvalitetsporten bestået?', som sender en fejl videre til 'Ret fejlen og byg igen' i stedet for fremad
• Promovering og staging som adskilte trin: artefaktet promoveres til registret, deployes til staging af pipelinen og tjekkes derefter af QA med smoke- og integrationstests inden beslutningen 'Er staging sund?', hvis fejlende gren også vender tilbage til fejlrettelsen
• Godkendelse med et reelt negativt udfald: den releaseansvarlige anmoder om et ændringsvindue i produktion, Drift træffer beslutningen 'Er deployment godkendt?', og et afslag ender forsøget i 'Deployment udskudt til næste vindue' i stedet for at køre videre i stilhed
• Deployment-strategien tegnet som en beslutning: 'Blue-green eller canary?' deler sig i deployment til det passive miljø eller til canary-instanserne, og begge grene mødes igen i 'Flyt trafik med health checks'
• Rollback og afslutning i Drift-banen: beslutningen 'Er fejlbudgettet overskredet?' sender en fejlende udrulning til 'Rul tilbage til forrige version' og videre ind i fejlrettelsen, mens en sund udrulning fuldføres, overvåges og lukkes i deployment-registreringen

Hvornår du skal bruge skabelonen

• I skal dokumentere, hvordan et build faktisk når produktion, i et team hvor deployment-trinnene lever i en pipeline-konfiguration og i hovedet på nogle få personer
• I skal aftale rollback-triggeren, før I får brug for den, så beslutningen bliver en målt tærskel frem for et skøn taget under pres på det værst tænkelige tidspunkt
• I skal onboarde udviklere, QA-folk og vagtpersonale, der har brug for at vide, hvilken port de ejer, og hvad der sker nedstrøms, når de holder den lukket
• I skal beslutte pr. service, om I deployer blue-green eller canary, og skrive valget ned et sted, hvor dem, der kører deploymentet, kan se det
• I skal svare en auditor eller en kunde på, hvordan en ændring bliver testet, godkendt og rullet tilbage, som supplement til jeres procedure for ændringsstyring

Sådan fungerer det

1. Omdøb banerne til jeres rigtige roller

   Erstat Udvikler, CI/CD-pipeline, QA, Releaseansvarlig og Drift med de roller, I faktisk har. Mange teams har ingen releaseansvarlig, og så skal den bane lægges ind hos den, der ejer produktion, frem for at stå tom. Behold CI/CD-pipelinen som sin egen bane, selvom den er automatik: hele pointen med diagrammet er at vise, hvilke trin en maskine udfører, og hvilke et menneske stadig udfører.

2. Skriv, hvad artefaktet er, og hvor det ligger

   Notér artefakttypen (container-image, pakke, bundle), versioneringsskemaet, hvordan versionen udledes af commit'et, hvilket register der opbevarer det, og hvor længe det gemmes. Skriv derefter den regel ned, resten af diagrammet hviler på: byg én gang, og promovér det samme artefakt. Byg aldrig igen pr. miljø. Bygger jeres pipeline om i dag, så markér det på diagrammet, for det bryder sammenhængen mellem det, der blev testet, og det, der blev leveret.

3. Definer, hvad hver port reelt tjekker

   'Kvalitetsporten bestået?' er kun så brugbar som sin definition. Angiv, hvilke testsuiter der skal være grønne, hvilken tolerance I accepterer for flaky tests og dækningsgrad, hvilke sikkerheds- og afhængighedsscanninger der blokerer buildet, og hvem der må tilsidesætte et rødt resultat. Gør det samme for smoke- og integrationstestene i staging, og list de kendte forskelle mellem staging og produktion (datamængde, tredjeparts sandkasser, nedskaleret infrastruktur), så alle ved, hvad en grøn staging-kørsel beviser, og hvad den ikke gør.

4. Fastlæg ændringsvinduet, og hvem der åbner det

   Skriv ned, hvornår deployments må køre, hvem der godkender dem, og hvad der sker med et deployment, der ikke bliver godkendt. Notér, om denne deployment-type er forhåndsgodkendt under en stående ændringsmodel eller kræver en individuel godkendelse hver gang, og udpeg den person, der kan godkende et deployment uden for normal arbejdstid. Hvis et udskudt deployment blot venter på næste vindue, så angiv, hvor længe artefaktet er gyldigt, før det skal bygges og testes igen.

5. Vælg en strategi pr. service, og skriv udrulningstrinnene

   Vælg blue-green eller canary for hver service, og sæt valget på diagrammet. Skriv derefter mekanikken: trafikandelene, hvor længe I observerer mellem dem, hvilke health checks der kører ved hvert trin, og hvad canary'en sammenlignes med. Håndtér databaseændringer for sig, for en skemamigrering er som regel grunden til, at et rollback ikke bare er en kontakt, man vipper tilbage; ved at adskille expand- og contract-migreringer fra kodedeploymentet holder I den gamle version kørbar.

6. Gør rollback-triggeren målbar, og udgiv så diagrammet

   Erstat 'nogen opdager det' med et signal, pipelinen selv kan vurdere: fejlrate eller svartid målt mod servicemålet over et defineret observationsvindue og med en aftalt handling. Øv jeres rollback, så I ved, hvor lang tid det tager. Del derefter diagrammet ved siden af runbooken, indhent godkendelse fra de personer, der står i det, hold én gældende version, og gennemgå det efter ethvert deployment, der gik skævt.

Ofte stillede spørgsmål

Hvad er forskellen på en deployment-proces og en releaseproces?

Releaseprocessen afgør, hvad der sendes af sted, og om det bør: hvilke ændringer der er i scope, hvornår scope fryses, hvem der godkender UAT, og om go/no-go-beslutningen er et ja. Deployment-processen er mekanikken nedenunder: byg et artefakt én gang, versionér det, promovér det, verificér det i staging, læg det ud på produktionsinfrastruktur, og rul det tilbage, hvis det opfører sig forkert. Forholdet er ikke én til én. Én release kan indeholde flere deployments, og masser af deployments sker helt uden en release: for eksempel når kode leveres bag et feature flag og slås til senere. Denne skabelon dækker mekanikken; har I brug for scope-fryse, UAT-godkendelse og en go/no-go-port, skal I bruge skabelonen for softwarereleaseprocessen i stedet.

Hvilke faser består en software deployment-proces af?

Fem faser dækker de fleste teams. Build og version: merge ændringen, byg artefaktet én gang fra et rent checkout, og stempl det med sit commit. Test og kvalitetsport: kør de automatiske tests og scanninger, og send fejl tilbage til udvikleren frem for videre frem. Staging: promovér artefaktet til registret, deploy det til staging, og kør smoke- og integrationstests mod det. Godkendelse og vindue: anmod om ændringsvinduet i produktion, og få deploymentet godkendt, eller udskyd det til næste vindue. Udrulning i produktion: deploy blue-green eller canary, flyt trafikken i trin med health checks, rul automatisk tilbage, hvis fejlbudgettet overskrides, og fuldfør ellers udrulningen, overvåg den og luk deployment-registreringen.

Skal vi deploye blue-green eller canary?

Blue-green kører to produktionsmiljøer og skifter trafikken mellem dem, så den forrige version bliver stående varm, og et skifte tilbage er næsten øjeblikkeligt. Prisen er cirka dobbelt kapacitet under deploymentet, og alle brugere flyttes i selve omskiftningsøjeblikket, så et problem, der først viser sig under rigtig trafik, rammer alle på én gang. Canary sender først en lille andel af den rigtige trafik til den nye version, hvilket afslører problemer, syntetiske tests ikke fanger, men det kræver trafikstyring og målinger, der kan opdeles pr. version, det tager længere tid, og det udsætter bevidst nogle brugere for en version, I endnu ikke er trygge ved. Ingen af dem løser databaseændringer: begge forudsætter, at den forrige version stadig kan køre mod det aktuelle skema, og derfor deles migreringer typisk op i expand- og contract-trin, der deployes hver for sig.

Hvornår skal et deployment rulle automatisk tilbage?

Når et signal, pipelinen selv kan vurdere, krydser en aftalt tærskel, ikke når et menneske fortolker et dashboard. I praksis betyder det fejlrate, svartid eller en navngiven forretningstransaktion målt mod servicemålet over et defineret observationsvindue, hvor udrulningen automatisk sættes på pause eller vendes, hvis forbruget af fejlbudgettet er værre end den aftalte grænse. To ting får det til at virke. For det første: øv rollbacket, så I ved, at det fungerer, og hvor lang tid det tager. For det andet: hold deploymentet reversibelt ved at adskille de uigenkaldelige trin (først og fremmest skemamigreringer og envejsændringer af data) fra kodedeploymentet, ellers vil automatikken forsøge et rollback, som dataene ikke kan bære.

Hvor passer godkendelsen ind, hvis vi deployer flere gange om dagen?

At godkende hvert enkelt deployment skalerer ikke, og en proces, folk ikke kan følge, bliver omgået. Det gængse svar er at godkende vejen frem for den enkelte kørsel: definer denne deployment-type som en forhåndsgodkendt standardændring, hvor pipelinens porte, tests og automatiske rollback er kontrollen, og gem den individuelle godkendelse til de ændringer, der falder uden for modellen: for eksempel skemamigreringer eller alt, der rører et lukket miljø. Det er der, beslutningen 'Er deployment godkendt?' ligger i dette diagram, og det er derfor, udskydelsesgrenen er tegnet. Rammeværk som SOC 2 (kriterium CC8.1) og ISO/IEC 27001's kontrol for ændringsstyring forventer, at ændringer i produktion er godkendte, testede og dokumenterede, de kræver ikke en menneskelig underskrift på hvert deployment. Et diagram er ikke i sig selv dokumentation, men de deployment-registreringer, testresultater og godkendelser, det frembringer, er det, en auditor beder om at se.