DORA Change Lead Time From commit to deploy

Change Lead Time – Wie schnell kommt dein Code zum Kunden?

Wie schnell kann dein Team auf neue Anforderungen reagieren?
Die Change Lead Time macht genau das messbar – sie zeigt, wie schnell Codeänderungen vom Commit bis zum produktiven Einsatz gelangen.

Die DORA-Metriken wurden vom DevOps Research and Assessment (DORA)-Team entwickelt 1, um die Leistungsfähigkeit von Softwareentwicklungsteams messbar zu machen. Sie basieren auf umfangreicher Forschung und Datenanalyse und unterstützen dabei, Entscheidungen auf einer fundierten, empirischen Grundlage zu treffen.

Eine der vier zentralen DORA-Metriken ist die Change Lead Time. In diesem Artikel erfährst du, was sie bedeutet, wie du sie misst und wie du sie gezielt verbessern kannst.

Was sind DORA-Metriken?

Die DORA-Metriken stammen aus der Forschung des DevOps Research and Assessment Teams, das über Jahre hinweg Daten von Tausenden Softwareprojekten analysiert hat. Ziel war es, messbare Kennzahlen zu identifizieren, die den Erfolg von Softwareentwicklungsteams vorhersagen können.

Die vier DORA-Metriken sind:

  • Deployment Frequency: Wie häufig werden Änderungen in Produktion gebracht?
  • Change Lead Time: Wie lange dauert es von der Codeänderung bis zum produktiven Einsatz?
  • Change Failure Rate: Wie oft führen Änderungen zu Fehlern in Produktion?
  • Time to Restore Service: Wie schnell wird ein fehlerhafter Zustand behoben?

Diese Metriken helfen Teams, ihre Entwicklungs- und Betriebsprozesse objektiv zu bewerten und gezielt zu verbessern.

Definition: Change Lead Time

Die Change Lead Time misst die Zeitspanne vom Commit einer Änderung im Quellcode bis zu deren erfolgreichem Deployment in Produktion. Diese Metrik gibt Aufschluss darüber, wie schnell ein Team auf Anforderungen reagieren kann – sei es durch neue Features, Bugfixes oder andere Änderungen.

Bedeutung der Metrik

Eine kurze Change Lead Time ist ein Indikator für effiziente Entwicklungsprozesse und schnelle Auslieferung. Sie steht in direktem Zusammenhang mit der Fähigkeit eines Teams, zeitnah auf Marktanforderungen oder Kundenfeedback zu reagieren.

Lange Lead Times können auf folgende Probleme hinweisen:

  • Manuelle Prozesse
  • Engpässe in der CI/CD-Pipeline
  • Komplexe Review- und Freigabeprozesse
  • Fehlende Automatisierung

DORA-Benchmarks

Die DORA-Forschung unterscheidet vier Leistungsstufen:

LeistungsstufeChange Lead Time
Elite< 1 Tag
High1–7 Tage
Medium1–4 Wochen
Low> 1 Monat

Diese Werte dienen als Orientierung für die Einordnung der eigenen Prozesse. Zur Selbsteinschätzung kann man die DORA-Metriken auch mit dem DORA Quick Check bewerten und mit verschiedenen Branchen vergleichen.

Messung der Change Lead Time

Zur Messung der Change Lead Time werden typischerweise folgende Zeitpunkte erfasst:

  • Commit-Zeitpunkt: Wann wurde die Änderung im Repository gespeichert?
  • Deployment-Zeitpunkt: Wann wurde die Änderung erfolgreich in Produktion gebracht?

Die Differenz zwischen diesen Zeitpunkten ergibt die Lead Time. Tools wie GitHub, GitLab können als Informationsquellen dienen und mit Tools wie Apache DevLake 2 oder Keptn 3direkt in DORA Metriken aufbereitet werden.

Optimierungsmöglichkeiten

Zur Verbesserung der Change Lead Time können folgende Maßnahmen beitragen:

  • Kleine, häufige Commits: Reduziert Komplexität und beschleunigt Reviews.
  • Automatisierte Tests und Deployments: Minimiert manuelle Schritte und Fehlerquellen.
  • Trunk-Based Development: Fördert kontinuierliche Integration.
  • Feature Toggles: Ermöglichen das sichere Ausrollen unfertiger Features.
  • Verkürzung von Feedbackzyklen: Schnelleres Review und Testing.

Fazit und Ausblick

Die Change Lead Time ist eine zentrale Kennzahl zur Bewertung der Geschwindigkeit und Effizienz von Softwareentwicklungsteams. Sie bietet klare Ansatzpunkte zur Prozessverbesserung und sollte regelmäßig gemessen und analysiert werden.

Im nächsten Beitrag widmen wir uns der Deployment Frequency – wie oft solltest du eigentlich deployen?

Bleib dran – und bring deine DevOps-Performance auf das nächste Level!

Simon Mennig

Über MICH

Simon Mennig hat Wirtschaftsinformatik (B.Sc.) an der Hochschule Ravensburg-Weingarten sowie Informatik mit Schwerpunkt Software Engineering (M.Sc.) an der HTWG in Konstanz studiert. Er arbeitet seit 2020 bei doubleSlash als Softwareentwickler und verfügt u.a. über Know-how in den Bereichen IoT, Cloud Computing und Java.

Alle Beiträge von Simon Mennig

Mehr erfahren

Weitere Infos auf unserer Website und in unserem Newsletter

Pfeil hoch