Slik begynner du å måle DORA-metrikker i et lite team

Et team på tre til ti utviklere kan måle alle fire DORA-metrikkene med det de allerede har: git, CI-loggen og en liste over hendelser. Her er hvordan, og hva du gjør med tallene etterpå.

Før du starter: definer «produksjon» og «feil»

To ting må være avklart, ellers blir tallene diskusjon i stedet for data:

• Hva er en deploy til produksjon? Normalt: en merge til hovedbranchen som rulles ut automatisk, eller en manuell utrulling som logges. Velg ett, og hold på det.
• Hva er en feil i produksjon? Normalt: en endring som må rettes med hotfix, rulles tilbake, eller gir en hendelse brukere merker. Ikke alle bugs, bare de som skyldes en nylig endring.

De fire tallene, og hvor du finner dem

Deployment frequency

Tell deployer per uke. Fra CI: antall vellykkede kjøringer av deploy-jobben. Fra git, hvis hver merge til main er en deploy:

git log --since="4 weeks ago" --merges --first-parent main --format="%ad" --date=short | sort | uniq -c

Lead time for changes

Tid fra en commit er laget til den er i produksjon. Enkleste mål: tiden fra en PR åpnes til den er merget og deployet. De fleste git-tjenester viser dette per PR; ta medianen for de siste 20.

Medianen, ikke gjennomsnittet. Én PR som lå i tre uker ødelegger ellers hele tallet.

Change failure rate

Antall deployer som førte til hotfix eller rollback, delt på antall deployer. Dette krever at dere merker hotfixer, for eksempel med en etikett på PR-en eller et ord i commit-meldingen. Start der: alle rettelser av produksjonsfeil merkes hotfix.

Failed deployment recovery time

Tid fra en feil oppdages til den er rettet i produksjon. Krever en liste over hendelser med to tidspunkt: oppdaget og rettet. Et regneark holder. Tidligere het denne metrikken «time to restore service».

Vis dem enkelt

Ett regneark eller én side i wikien, oppdatert hver uke, med fire tall og trenden fra forrige måned. Ingen dashboards i første omgang. Det viktige er at teamet ser tallene sammen, for eksempel i retro.

Eksempelet over er typisk for et team som har begynt å deploye oftere: farten går opp, og feilraten går litt opp i starten fordi det er flere endringer å telle. Det jevner seg ut når endringene blir mindre.

Når tallene ikke blir bedre

• Lang lead time: Finn køen. Hvor lenge venter en PR på review? Hvor lang er testkjøringen? Hvor mange godkjenninger kreves? Fjern én kø om gangen.
• Lav deploy-frekvens: Endringene er for store. Del oppgavene opp til de kan merges på én dag.
• Høy feilrate: Mangler automatiske tester på det som feiler oftest. Skriv testen for den siste feilen, hver gang.
• Lang recovery time: Ingen vet hvordan de ruller tilbake. Øv på det, i rolige tider.

Etter tre måneder

Da har dere tolv ukers data og kan se om innførte endringer, for eksempel AI-verktøy i utviklingen, faktisk gjorde noe. Det er hele grunnen til å måle. Les Slik kommer teamet i gang med AI-assistert utvikling for hva som bør måles før og etter.