Flowchart for software release-processen

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.