Flowchart for software deployment: fra build til produktion

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.