I nogle softwarehuse holder alle vejret, når en ny version sendes ud. Den store udgivelse er planlagt til søndag aften, udviklerne står klar, og mandag morgen er supporten fuld. Det virker fornuftigt at samle ændringerne og udgive sjældent, men det gør risikoen større. Jo flere ændringer der går ud samtidig, jo sværere er det at finde ud af, hvad der gik galt, og jo mere frygter teamet det næste forsøg. Vejen ud er mindre og hyppigere udgivelser og nogle få faste rutiner. Det lyder modsat af sund fornuft, og det er grunden til, at ledelsen skal forstå det.
Hvorfor store udgivelser skaber fejl
En release (udgivelse) er det øjeblik, en ændring når kunderne. Samler I tre måneders arbejde i én udgivelse, sker der fire ting:
- Ændringerne påvirker hinanden på måder, ingen har testet.
- Når noget går galt, er der hundreder af mulige årsager.
- Udviklerne husker ikke længere detaljerne i det, de lavede for to måneder siden.
- Tilbagerulning bliver svær, fordi data og andre ændringer har flyttet sig imens.
Når det så gør ondt, reagerer mange ved at udgive endnu sjældnere og lægge flere kontroller på. Det gør pakken større og problemet værre. En lille ændring, der går ud samme dag, den er færdig, kan forstås, testes og fjernes igen.
De rutiner, der ændrer det
Et lille team behøver ikke meget. Disse seks rutiner står for det meste af virkningen, og mange kan indføres trinvis:
Automatisk bygning og test. Hver ændring bygges og testes af en maskine, før den kan komme videre. Det kaldes en CI/CD-pipeline. Det er forudsætningen for resten. Testen må gerne starte lille, når blot kerneflowet er dækket.
Kodegennemgang. Ændringer læses af en kollega, før de går videre. Det fanger fejl og spreder viden, se udviklingsprocessen til et lille team.
Funktionsflag (feature flags). En kontakt i koden, der gør det muligt at sende ny kode ud uden at tænde funktionen. Så kan udgivelse af kode og åbning for kunderne adskilles, og funktionen kan slås fra uden en ny release. Ryd op i flagene efterhånden, for gamle flag er gæld.
Trinvis udrulning. Lad ændringen ramme en lille gruppe kunder eller egne medarbejdere først. Går noget galt, er skaden begrænset.
Tilbagerulning (rollback). Muligheden for hurtigt at gå tilbage til forrige version. Øv den. Sværest er databaseændringer, som bør laves, så ny og gammel kode kan leve side om side i en periode, fx ved at tilføje kolonner først og fjerne de gamle senere.
Overvågning efter hver udgivelse. Sammenlign fejl og svartider før og efter. Den, der har lavet ændringen, bør følge med i den første tid, se overvågning, vagt og driftshændelser.
Hvor mange miljøer har I brug for?
Et miljø er en kørende udgave af produktet. Mange teams opbygger for mange og vedligeholder dem dårligt. Som udgangspunkt rækker tre:
- Udvikling. Lokalt hos udvikleren eller et lille delt miljø.
- Test (staging). Så tæt på produktion som muligt, og med data, der ligner virkeligheden, uden at være rigtige persondata.
- Produktion. Det, kunderne bruger.
Flere miljøer giver sjældent mere sikkerhed. Hvert ekstra miljø skal holdes ajour, og et testmiljø, der afviger fra produktion, giver falsk tryghed. Har ændringer brug for at blive vist til en kunde, kan et midlertidigt miljø pr. ændring være en bedre løsning end endnu et fast miljø.
Har I faste kunder, der gerne vil kende datoen for nye funktioner, kan det aftales med funktionsflag. Kode kan gå ud dagligt, mens en større ændring åbnes for kunderne på en aftalt dato.
Sådan måler I, om det bliver bedre
DORA-målingerne kommer fra et forskningsprogram om softwareudvikling og har intet at gøre med EU-forordningen af samme navn, som rammer den finansielle sektor. Målingerne ser på, hvor hurtigt en ændring når produktion, hvor tit I udgiver, hvor ofte en udgivelse kræver indgriben, og hvor hurtigt I kommer jer efter en fejlet udgivelse. Hastighed og stabilitet ses sammen, og det er pointen.
Brug dem til at følge jeres eget team over tid. DORA advarer selv mod at gøre tallene til mål eller sammenligne hold, for så får folk en grund til at pynte på dem. Stil et enkelt spørgsmål til teamet hver måned: Hvad gjorde den seneste udgivelse besværlig? Brug svaret til at vælge næste forbedring. Er tempoet faldet bredt, så læs om langsommere udvikling.
Rækkefølgen for et team, der er presset
Hvis I står i det nu, kan I ikke ændre det hele på en gang. Et godt forløb kan se sådan ud:
- Få automatisk bygning og udrulning op at køre, så der ikke er manuelle trin.
- Dæk kerneflowet med automatiske test.
- Gør den næste udgivelse mindre end den forrige, også selvom det kræver, at en del udskydes.
- Indfør tilbagerulning, og øv den.
- Tag funktionsflag ind, når behovet er der.
Der er også et ledelsesspørgsmål. En fast datofrist, hvor alt skal med, driver pakkerne op. Lad køreplanen vise rækkefølge frem for faste leverancer, og lad salget vide, at en funktion kan frigives, når den er klar, se løfter fra salg.
Et kort stop for ændringer før ferier eller travle kundeperioder er stadig rimeligt. Er produktet omfattet af Cyber Resilience Act, hører det også med i releaseprocessen at vurdere, om en ændring er væsentlig.
Det skal I lade være med
· At samle ændringer for at være på den sikre side.
· At lægge flere manuelle godkendelser på, hver gang noget går galt.
· At udgive fredag eftermiddag uden nogen på vagt.
· At gøre udgivelsestal til en konkurrence mellem udviklerne.
Det skal I kræve af den eksterne
- ☐ Et billede af, hvordan en ændring når produktion i dag, trin for trin.
- ☐ En plan for at fjerne manuelle trin.
- ☐ En aftalt og øvet tilbagerulning.
- ☐ En enkel opgørelse af udgivelser og fejl over tid.
- ☐ En anbefaling om antal miljøer.
Kilder
- DORA: Software delivery metrics: målingerne og advarslen mod at gøre dem til mål.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Produktet var nede: dagen efter · Hvem ejer driften?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
