Kostenlose DevOps-Analyse
Zurück zum Glossar
DevOps Glossar·CI/CD·Zuletzt geprüft

Deployment Frequency

// Direkte Antwort

Warum ist die Deployment Frequency wichtig?

Die Deployment Frequency misst, wie oft ein Team Software in Produktion bringt. Sie ist eine der DORA-Metriken und gilt als Indikator dafür, wie schnell eine Organisation auf Anforderungen reagieren kann. Im DORA-Report 2024 liefert das Elite-Cluster auf Abruf mehrmals täglich aus, das Low-Cluster monatlich bis halbjährlich.

Auch bekannt als: Deployment-Frequenz · Bereitstellungshäufigkeit · DORA Deployment Frequency

// Kurz gefragt1 Klick, anonym

Ist Deployment Frequency bei Ihnen gerade ein Thema?

Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.

// Im DetailDeployment Frequency

Gezählt wird jedes erfolgreiche Deployment in Produktion, nicht jeder Commit und nicht jeder Build. DORA definiert die Kennzahl als Zahl der Deployments in einem Zeitraum oder als Zeit zwischen zwei Deployments. In Umfragen fragt DORA sie in Bändern ab, von „mehrmals täglich" bis „seltener als alle sechs Monate". Wer selbst misst, zählt die Deployment-Events der Pipeline pro Service und Woche und schaut auf den Median über mehrere Wochen. Ein einzelner Release-Tag mit zwanzig Deployments verzerrt sonst das Bild.

Die Deployment Frequency ist eine Durchsatz-Metrik und ergibt nur neben den Stabilitätswerten einen Sinn. Häufiges Ausliefern zahlt sich aus, wenn Change Failure Rate und Failed Deployment Recovery Time mithalten. Im DORA-Report 2024 deployte das Elite-Cluster auf Abruf, also mehrmals täglich, das High-Cluster zwischen täglich und wöchentlich, das Medium-Cluster zwischen wöchentlich und monatlich und das Low-Cluster zwischen monatlich und halbjährlich. Steigt die Frequenz, liegt das fast immer an kleineren Batches, automatisierten Pipelines und Services, die sich unabhängig voneinander ausrollen lassen.

In der Industrie bremsen Wartungsfenster, Sicherheitsfreigaben und Zertifizierungen die Frequenz. Eine Steuerung, die nur im Stillstand am Wochenende aktualisiert werden darf, bekommt keine drei Deployments am Tag. Das ist kein Grund, die Metrik zu ignorieren. Messen Sie getrennt: die Backend- und MES-Services, die jederzeit ausgeliefert werden können, und die Anlagen-Software, die an Fenster gebunden ist. So sehen Sie, ob ein seltener Release am Fenster hängt oder an der eigenen Pipeline.

Der typische Fehler ist, die Frequenz zum Ziel zu erklären. Treibt ein Team die Zahl hoch, ohne Tests mitzuziehen, steigt die Change Failure Rate, und nach dem dritten Rollback in einer Woche kehrt der Freigabemarathon zurück. Lesen Sie die Frequenz als Diagnose. Sie zeigt, dass etwas seltene Releases erzwingt, und die Arbeit besteht darin, dieses Etwas zu finden.

// Beispiele aus der Praxis2 Szenarien
/01

Vom monatlichen Big-Bang-Release zum Dienstag ohne Freigaberunde

Ein Fertigungs-IT-Team sammelte Änderungen einen Monat lang und spielte sie in einer langen Nacht gemeinsam ein. Es ersetzt den Big-Bang-Release durch eine automatisierte Pipeline mit Feature Flags, die Code ausliefern, ohne ihn gleich für Nutzer freizuschalten. Die Deployment Frequency steigt auf mehrere Releases pro Tag, die Change Failure Rate bleibt gleich. Woran das Team den Unterschied merkt: An einem gewöhnlichen Dienstag geht ein Release raus, und niemand hat dafür eine Besprechung angesetzt.

/02

Manuelle Freigaben als eigentliche Bremse

Ein Automotive-Embedded-Team deployte alle sechs Wochen und vermutete die langsame Build-Umgebung als Ursache. Die Auswertung zeigt, dass jedes Release zwei manuelle Freigaben und eine händische Testrunde durchläuft. Das Team automatisiert die Tests und ersetzt eine Freigabe durch eine Regel in der Pipeline. Die Frequenz steigt danach von selbst, ohne dass jemand eine Zielzahl vorgegeben hat.

// Welcher Weg passt?Deployment Frequency
// In 2 Klicks: Öfter deployenSchritt 1 / 2

Was bremst Ihre Deployment Frequency?

Selten zu deployen ist selten Absicht — meist steckt eine konkrete Bremse dahinter. Zwei Klicks zeigen, wo Sie ansetzen.

Was hält Sie am meisten auf?

// Häufige FragenFAQ
Wie misst man die Deployment Frequency richtig?
Zählen Sie die erfolgreichen Produktiv-Deployments pro Service in einem festen Zeitraum und bilden Sie den Median über mehrere Wochen. Die Daten kommen am zuverlässigsten aus der Telemetrie der Pipeline: Jeder Deployment-Job, der gegen die Produktionsumgebung erfolgreich endet, schreibt ein Event mit Service, Zeitstempel und Version. Builds, Deployments in Test-Umgebungen und abgebrochene Läufe zählen nicht mit.
Macht eine hohe Deployment Frequency das System nicht instabiler?
Nein, meist ist es umgekehrt: Kleine, häufige Deployments enthalten weniger Änderungen und lassen sich leichter testen und zurückrollen. Laut DORA bewegen sich Durchsatz und Stabilität in allen vier Clustern des Reports 2024 gemeinsam, das Elite-Cluster deployt am häufigsten und hat zugleich die niedrigste Change Failure Rate. Instabil wird es, wenn die Frequenz steigt und die Tests zurückbleiben.
Welche Maßnahmen erhöhen die Deployment Frequency dauerhaft?
Kleinere Batches, vollständig automatisierte CI/CD-Pipelines, Trunk-based Development und Services, die sich einzeln ausrollen lassen. Feature Flags trennen das Deployment vom Release, sodass Code in Produktion liegen kann, bevor Nutzer ihn sehen. Welche Maßnahme zuerst kommt, entscheidet der Engpass: Wartet ein Release auf Freigaben, hilft eine schnellere Pipeline wenig.
Worin unterscheidet sich Deployment Frequency von Release Frequency?
Die Deployment Frequency zählt, wie oft Code technisch in Produktion gelangt, die Release Frequency, wie oft Funktionen für Nutzer freigeschaltet werden. Mit Feature Flags laufen beide auseinander: Das Team deployt täglich, das Produktmanagement schaltet die neue Funktion erst zum geplanten Termin frei.
// Ihre Einschätzung1 Klick, anonym

Wo steht Ihr Team bei Deployment Frequency?

Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.

// Quellen und Referenzen3 Quellen

Weiterführende Primärquellen zu Deployment Frequency: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.

// Nächster Schritt

Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.

Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.

Erstgespräch buchen
Seit 2006 · 47+ Projekte
Industrie · Automotive · Finance