Flowchart for software release-processen

Hvad er flowchart for software release?

En software release-proces er de porte, der ligger mellem et færdigt build og et stabilt produktionsmiljø. Selve trinnene er velkendte (opret en branch, byg den, test den, send den ud), men værdien af at skrive processen ned ligger i portene: det punkt, hvor omfanget holder op med at ændre sig, det punkt, hvor en fejlet testkørsel sender arbejdet tilbage til udvikling i stedet for videre, det punkt, hvor en person med beføjelse til det siger go, og det punkt, hvor en dårlig release rulles tilbage i stedet for at blive diskuteret. Hver port efterlader en optegnelse over, hvad der var med i releasen, hvad der blev testet, hvem der godkendte den, og hvad der skete efter idriftsættelsen.

De fleste release-problemer er overleveringsproblemer, ikke tekniske problemer. En branch bliver oprettet, mens tre merges stadig er undervejs, så ingen kan sige, hvad buildet reelt indeholder. QA kører en regressionspakke mod et staging-miljø, der for længst er drevet væk fra produktion. Go/no-go-beslutningen falder på et videomøde uden nedskrevne kriterier, så den højeste stemme vinder. En release går ud sidst på eftermiddagen uden en aftalt overvågningsperiode, og det første tegn på problemer er en kundemail næste morgen. Når flowet tegnes som swimlanes, bliver hver overlevering eksplicit, og man kan se, hvem der holder releasen lige nu.

Skabelonen er et reelt release-flow fordelt på fem baner (Udvikling, QA, Release manager, Drift og Produktejer) lagt ud over fem faser fra frys af omfang til lukning. Den indeholder de tre løkker, teams som regel undlader at tegne: den automatiske testport, der sender fejl tilbage til release-branchen, no-go-beslutningen, der sender en release retur til udbedring i stedet for ud ad døren, og hotfix-vejen, der lader en fejl fundet efter release komme tilbage gennem deployment og verifikation, uden at nogen opfinder en parallel proces.

Hvad dette flowchart dækker

I denne skabelon

• Omfang og branch på tværs af de tre første baner: koden er færdig i Udvikling, QA bekræfter testomfang og indgangskriterier, og release manageren fryser omfanget og opretter release-branchen
• Den automatiske testport: Udvikling bygger og kører de automatiske tests, hvorefter QA ejer beslutningen 'Består de automatiske tests?', som sender fejl videre til 'Ret fejl på release-branchen' og tilbage i buildet frem for fremad
• Staging og UAT som tre adskilte overleveringer: Drift deployer buildet til staging, QA kører regressionstest mod det, og produktejeren kører UAT og registrerer godkendelsen
• Godkendelse som både dokumentation og beslutning: release manageren samler dokumentationen for release-parathed, produktejeren godkender releasen til produktion, og beslutningen 'Go eller no-go?' sender den enten videre eller retur til fejlrettelsen
• Produktionsvejen i Drift-banen: deploy i release-vinduet, smoke-test i produktion og derefter beslutningen 'Er releasen sund?', der leder en fejlende release til 'Rul tilbage til forrige version' og videre tilbage i fejlrettelsen
• Overvågning og lukning: en defineret soak-periode, beslutningen 'Fejl fundet i produktion?', der føder hotfix-løkken tilbage gennem deployment og smoke-test, og et sidste trin, der udgiver release notes og lukker releasen

Hvornår du skal bruge skabelonen

• I skal skrive eller omskrive en release-procedure for et team, der hidtil har sendt ud efter vane og chattråde, og har brug for ét fælles billede, før det bliver kodet ind i en pipeline
• I onboarder nye udviklere, testere eller vagtpersonale, der skal vide, hvilken port de ejer, og hvad der sker nedstrøms, hvis de holder den lukket
• I skal afgøre, hvem der reelt træffer go/no-go-beslutningen, og efter hvilke kriterier, inden næste release tvinger diskussionen frem
• I skal besvare et sikkerhedsspørgeskema fra en kunde eller en intern revisionsanmodning om, hvordan ændringer testes, godkendes og rulles tilbage
• I evaluerer processen efter en dårlig release, så diskussionen handler om, hvilken port der blev sprunget over, i stedet for en rekonstruktion fra hukommelsen

Sådan fungerer det

1. Omdøb banerne til jeres faktiske roller

   Erstat Udvikling, QA, Release manager, Drift og Produktejer med de roller, I reelt har. Mange teams har ingen dedikeret release manager, så læg den bane sammen med den tekniske ledelse frem for at lade et tomt bånd stå. Har I ikke et separat driftsteam, så flyt deployment ind under Udvikling, og skriv det på diagrammet.

2. Definér hvad frysningen af omfanget betyder

   Skriv jeres frysningsregel ved siden af trinnet med release-branchen: hvad må stadig lande på branchen efter oprettelsen, hvem godkender en undtagelse, og hvordan tagges branchen. Notér den commit, branchen blev oprettet fra: det er den, der gør buildet reproducerbart og lader jer generere release notes ud fra diffen.

3. Definér hvad 'bestået' betyder ved hver testport

   Beslutningen 'Består de automatiske tests?' er kun så god som sin definition. Skriv, hvilke testsuiter der skal være grønne, hvilken grænse I accepterer for flaky tests og dækning, og hvem der må tilsidesætte et rødt build. Gør det samme for regressionspakken på staging og for UAT, så produktejeren ved, hvad der skrives under på.

4. Skriv go/no-go-kriterierne, før I får brug for dem

   Erstat den generiske beslutning med jeres egen tjekliste: ingen åbne kritiske fejl, rollback afprøvet, vagtdækning bekræftet, afhængige teams orienteret og et aftalt sidste tidspunkt. Navngiv, hvem der leder mødet, og hvem der kan nedlægge veto. At aftale det, mens en release allerede venter, er præcis sådan dårlige releases bliver godkendt.

5. Fastlæg rollback-triggeren, soak-perioden og hotfix-vejen

   Skriv, hvad der får 'Er releasen sund?' til at svare fejler: en konkret fejlrate, en latensgrænse eller en fejlet smoke-test, ikke et skøn. Sæt længden på soak-perioden og hvad der overvåges. Aftal derefter, hvilken godkendelse en hotfix kræver, hvem der må godkende den uden for arbejdstid, og hvordan den merges tilbage til mainline, for en rettelse, der kun lever på release-branchen, er en klassisk kilde til næste regression.

6. Udgiv det, og hold én gældende version

   Del diagrammet der, hvor arbejdet foregår, ved siden af release-tjeklisten eller i runbooken, og få godkendelse fra de personer, der er nævnt i det. Gem de tidligere versioner, så I kan vise, hvornår proceduren blev ændret og hvorfor, og gennemgå den efter enhver release, der gik skævt.

Ofte stillede spørgsmål

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

Fem faser dækker de fleste teams. Først omfang og branch: bliv enige om, hvad der er med, bekræft indgangskriterierne for test, frys omfanget og opret release-branchen. Dernæst build og test: producer en release candidate, kør den automatiske testpakke, og send fejl tilbage til branchen i stedet for fremad. Så staging og UAT: deploy til et staging-miljø, kør regressionstest, og få UAT-godkendelse fra produktejeren. Derefter godkendelse: saml dokumentationen for release-parathed, og træf en eksplicit go/no-go-beslutning. Til sidst release og overvågning: deploy i det aftalte vindue, kør smoke-test, hold øje i en defineret soak-periode, og udgiv så release notes og luk releasen.

Hvad er forskellen på en release-proces og en deployment-pipeline?

En deployment-pipeline er automatikken: den bygger, tester og udsender kode, når den trigges. Release-processen er beslutningerne omkring den: hvem aftalte omfanget, hvem bekræftede at testene var meningsfulde, hvem godkendte produktion, hvad sker der, når releasen går galt, og hvornår kan teamet slappe af igen. En moden pipeline fjerner manuelle trin, men den fjerner ikke beslutningerne. Diagrammet viser bevidst beslutningerne som beslutninger, så I kan se, hvilke af dem jeres pipeline allerede håndhæver, og hvilke der stadig afhænger af, at nogen husker det.

Hvem bør træffe go/no-go-beslutningen, og på hvilket grundlag?

Én navngiven person bør lede den (typisk release manageren eller den, der ejer produktion) med produktejerens godkendelse allerede registreret som input frem for diskuteret på mødet. Træf beslutningen ud fra kriterier skrevet før releasen: ingen åbne kritiske fejl, regressionstest og UAT gennemført, rollback afprøvet, vagtdækning bekræftet og afhængige teams orienteret. Notér hvem der deltog, og hvad der blev besluttet, ikke bare udfaldet. Bliver I auditeret efter SOC 2, er det relevante kriterium CC8.1, som forventer, at ændringer er autoriserede, testede, godkendte og dokumenterede; dokumentationen for release-parathed og godkendelsessporet er det, der påviser netop det, og diagrammet viser, hvor de bliver skabt.

Hvordan håndterer man hotfixes uden at omgå release-processen?

En hotfix komprimerer processen: den springer den ikke over. I denne skabelon sendes en fejl fundet i overvågningsperioden videre til 'Byg og test en hotfix' i Udvikling-banen og kommer derefter ind igen ved deployment og gennem de samme smoke-tests i produktion og det samme tjek 'Er releasen sund?' som en planlagt release. Det, der ændrer sig, er godkendelsens hastighed, ikke verifikationen. To regler holder det ærligt: aftal på forhånd, hvem der må godkende en hotfix uden for arbejdstid, og merge rettelsen tilbage til mainline samme dag, for en rettelse, der kun findes på release-branchen, dukker op igen som en regression i næste release.