Aktualisiert am 13. Oktober 2026 von Nicolas Finet, CEO von Sortlist. Neu sind das seit 2024 erweiterte DORA-Kennzahlenmodell, ein Vergleich aktueller Release-Werkzeuge, ein Risikorechner und eine operative Checkliste. Damit können Sie Releases nicht nur planen, sondern anhand von Durchsatz, Stabilität und Wiederherstellungszeit steuern.
Das Wichtigste in Kürze
- Release Management koordiniert Umfang, Risiken, Freigaben und Kommunikation; Deployment bezeichnet die technische Übertragung in eine Zielumgebung.
- DORA bewertet Software Delivery seit 2024 mit fünf Kennzahlen: drei für den Durchsatz und zwei für die Instabilität.
- Ein belastbarer Release-Prozess braucht automatisierte Tests, nachvollziehbare Freigaben, Monitoring sowie einen vorab geprüften Rollback-Plan.
Was sich beim Release Management geändert hat
Release und Deployment Management plant, definiert und kontrolliert nach dem IT Process Wiki, wie ein Release getestet und in die Live-Umgebung ausgerollt wird. Release Management ist dabei die organisatorische Klammer; ein Deployment ist ein technischer Vorgang und muss nicht automatisch bedeuten, dass eine Funktion sofort für alle Nutzer freigeschaltet wird.
Gegenüber dem ursprünglichen Artikel rücken 2026 kleinere Änderungen, automatisierte Qualitätsprüfungen, gestaffelte Rollouts und messbare Wiederherstellung stärker in den Vordergrund. Das ergänzt die Schutzfunktion des Release Managements: Updates sollen ihren versprochenen Nutzen liefern, ohne Leistung oder Zuverlässigkeit zu beeinträchtigen, wie auch die am 27. September 2023 veröffentlichte Freshservice-Einordnung zum Release Management betont.
Release-Strategien im Vergleich
| Strategie | Geeignet für | Kontrollmechanismus | Wesentliches Risiko |
|---|---|---|---|
| Fester Release-Zyklus | Produkte mit planbaren Sammelreleases | Release-Kalender und formale Freigabe | Große Änderungspakete erschweren die Fehlersuche |
| Continuous Delivery | Digitale Produkte mit automatisierter Pipeline | Tests, Security-Gates und reproduzierbare Builds | Schwache Automatisierung vervielfacht manuelle Fehler |
| Canary Release | Systeme mit messbarem Nutzerverkehr | Auslieferung an einen begrenzten Nutzeranteil | Ungeeignete Messwerte können Fehler zu spät zeigen |
| Blue-Green Deployment | Kritische Dienste mit schneller Umschaltung | Zwei getrennte Produktionsumgebungen | Zusätzlicher Infrastruktur- und Datenabgleichsaufwand |
| Feature Flags | Funktionen, die unabhängig vom Deployment aktiviert werden | Zielgruppenregeln und sofortiges Abschalten | Alte Flags erzeugen technische und organisatorische Schulden |
Fünf Kennzahlen für belastbare Releases
Die am 5. Januar 2026 aktualisierte DORA-Systematik trennt Durchsatz und Instabilität. Messen Sie die Werte pro Anwendung und Zeitraum, statt Ergebnisse verschiedener Systeme ohne Kontext zu vermischen.
- 5 Kennzahlen: DORA erweiterte sein Modell 2024 von vier auf fünf Software-Delivery-Metriken.
- 3 Durchsatzmetriken: Change Lead Time, Deployment Frequency und Failed Deployment Recovery Time.
- 2 Instabilitätsmetriken: Change Fail Rate und Deployment Rework Rate.
- 0 bis 10 Punkte: Der am 22. April 2026 aktualisierte DORA Quick Check verdichtet die fünf Werte zu einem Vergleichsscore auf Basis des Forschungsprogramms 2025.
Die Change Fail Rate ist der Anteil der Deployments, die unmittelbar einen Eingriff wie Rollback oder Hotfix erfordern. Die Deployment Rework Rate erfasst dagegen ungeplante Deployments, mit denen produktive Fehler behoben werden. Diese Trennung verhindert, dass ein Team eine hohe Auslieferungsfrequenz als Erfolg wertet, obwohl ein großer Teil der Arbeit aus Nachbesserungen besteht.
DORA bewertet Software Delivery seit 2024 nicht mehr nur über vier Schlüsselmetriken: Die Deployment Rework Rate macht ungeplante Fehlerbehebung als fünfte Kennzahl sichtbar.
Zusammenfassung der DORA-Forschung, zuletzt aktualisiert am 2. Januar 2026
Release-Werkzeuge 2026: Features und Bewertung
Die Wahl sollte Ihrer vorhandenen Code-Plattform, den Compliance-Anforderungen und dem Betriebsmodell folgen. Die folgende Bewertung ist eine redaktionelle Einordnung, keine Nutzerbewertung.
| Werkzeug | Wichtige Features | Bewertung (redaktionell) |
|---|---|---|
| GitHub Actions | Repository-nahe Workflows, Environments, Freigaben und Deployment-Schutzregeln | Sehr gut für Teams, deren Entwicklung bereits vollständig auf GitHub liegt |
| GitLab CI/CD | Integrierte Pipelines, Environments, Releases und Nachweise innerhalb einer Plattform | Sehr gut für eine durchgängige DevSecOps-Toolchain mit wenig Systemwechseln |
| Azure Pipelines | Mehrstufige Pipelines, Environments sowie Freigaben und Checks | Stark für Microsoft- und hybride Unternehmensumgebungen |
| Jenkins | Erweiterbare Open-Source-Automatisierung und große Plugin-Auswahl | Flexibel für individuelle Alt- und Mischumgebungen, aber mit höherem Wartungsbedarf |
| Freshservice | ITSM-orientierte Planung, Change-Bezug, Freigaben und Release-Koordination | Gut für Organisationen, die Governance und Service Management priorisieren |
Keines dieser Werkzeuge ersetzt klare Verantwortlichkeiten. Automatisierte Tests lassen sich beispielsweise mit Test-Driven Development vorbereiten; bei externer Unterstützung sollten Sie außerdem Abhängigkeiten und Wissenstransfer berücksichtigen, wie unser Leitfaden zum IT-Outsourcing erläutert.
Mini-Rechner: operative Release-Belastung abschätzen
Tragen Sie Ihre Monatswerte ein. Der Rechner ermittelt erwartete fehlgeschlagene Deployments, daraus entstehende Wiederherstellungsstunden und ungeplante Nachbesserungs-Deployments. Die voreingestellten Werte sind ausschließlich ein editierbares Rechenbeispiel und keine Branchenbenchmarks.
Checkliste für den nächsten Release
- Umfang festlegen: Tickets, Abhängigkeiten, Datenmigrationen und ausgeschlossene Änderungen eindeutig dokumentieren.
- Verantwortung benennen: Release Manager, technische Freigabe, Product Owner, Security und Incident-Verantwortliche zuordnen.
- Qualitätsnachweise prüfen: Automatisierte Tests, manuelle Abnahmen, Sicherheitsprüfungen und Build-Artefakte nachvollziehbar ablegen.
- Rollout und Rollback proben: Abbruchkriterien, Rücksetzpfad, Datenkompatibilität und Entscheidungsbefugnis vor dem Produktionsstart klären.
- Monitoring vorbereiten: Technische Fehler, Latenz und fachliche Kerntransaktionen mit Ausgangswerten und Alarmgrenzen überwachen.
- Nachbereitung terminieren: DORA-Kennzahlen, Zwischenfälle und Verbesserungsmaßnahmen mit Verantwortlichen und Fristen festhalten.
Backups sind dabei nur hilfreich, wenn ihre Wiederherstellung geprüft wurde. Ergänzende Hinweise finden Sie im Sortlist-Beitrag zur WordPress-Sicherheit.
Benötigen Sie externe Unterstützung für CI/CD, Qualitätssicherung oder Release-Governance? Beschreiben Sie Ihr Projekt und finden Sie passende Partner.
Häufige Fragen zu Release Management
Was ist der Unterschied zwischen Release und Deployment?
Ein Deployment überträgt eine technische Änderung in eine Zielumgebung. Ein Release umfasst zusätzlich Planung, Freigabe, Kommunikation und die Entscheidung, wann eine Änderung für Nutzer verfügbar wird. Feature Flags können beide Zeitpunkte voneinander trennen.
Welche Aufgaben hat ein Release Manager?
Der Release Manager koordiniert Umfang, Termine, Abhängigkeiten, Freigaben, Kommunikation und Nachbereitung. Die Rolle führt nicht zwingend jedes Deployment selbst aus, stellt aber sicher, dass Risiken, Verantwortlichkeiten und Rückfalloptionen transparent sind.
Welche Kennzahlen sollten Unternehmen messen?
Als belastbare Basis dienen Change Lead Time, Deployment Frequency, Failed Deployment Recovery Time, Change Fail Rate und Deployment Rework Rate. Ergänzend können geschäftsspezifische Werte wie abgebrochene Bestellungen oder fehlerhafte Transaktionen erforderlich sein.
Ist Continuous Delivery dasselbe wie Continuous Deployment?
Nein. Bei Continuous Delivery bleibt eine geprüfte Änderung jederzeit auslieferbar, die Produktionsfreigabe kann jedoch bewusst erfolgen. Continuous Deployment veröffentlicht jede Änderung automatisch, sobald alle definierten Prüfungen bestanden sind.
Wann sollte ein Release zurückgerollt werden?
Die Entscheidung sollte auf vorab festgelegten Abbruchkriterien beruhen, etwa kritischen Sicherheitsfehlern, beschädigten Daten oder einer deutlichen Verschlechterung zentraler System- und Geschäftsmetriken. Ist ein Rollback wegen einer Datenmigration riskanter als eine Korrektur, braucht das Team einen geprüften Vorwärtsbehebungsplan.
Release Management ist ein wichtiger Prozess, der einen effizienten Umgang mit neuer IT-Software ermöglicht. Dazu gehört das Planen, Entwerfen, Testen, zur Verfügung stellen und das Kontrollieren des Software-Releases.
Mit Release Management erhalten Sie einen Gesamtüberblick über die Entwicklungsphasen und den Zeitplan, wenn Webanwendungen, Updates oder Software-Lösungen neu in eine Firmen-IT integriert werden. All dies geschieht in Zusammenarbeit mit dem Change Management und dem Configuration Management.
Generelle Informationen zum Release Management
Als Release Management wird der Prozess in einem Unternehmen bezeichnet, mit dem Patches, Updates, Rollouts oder andere Veränderungen orchestriert werden. Ziel ist es, das Unternehmen immer auf dem neuesten Stand in Sachen digitaler Technik zu halten, ohne dabei die täglichen Arbeitsprozesse der Mitarbeiter und der unterschiedlichen Abteilungen zu stören.
Dabei erfolgt die Durchführung nach den generellen Regeln des Projektmanagements. Das Besondere: in vielen Fällen finden diese Transitionen und Aktualisierungen in einer Live-Produktionsumgebung statt, ohne das Maschinen für lange Zeit abgeschaltet werden.
Wichtige Eckpunkte für die Planung sind:
- Festlegung des Funktionsumfangs der gewünschten Anwendung.
- Der Zeitplan wird definiert und dessen Einhaltung wird kontinuierlich überprüft.
- Eine Qualitätskontrolle ist unabdingbar.
- Dokumentation aller Änderungen ist ausschlaggebend, um die Prozesse bei zukünftigen Aktualisierungen zu wiederholen.
Die Koordination für diesen Prozess, der zum Beispiel eine neue Software in die Firmenstruktur einführt, findet meist auf mittlerer Führungsebene statt. Dabei werden im generellen drei Arten für das Release Management unterschieden.
Emergency Release
Emergency Release sind Software- oder Produktversionen, die nur kurzfristig verfügbar sind. Man spricht hier auch von Bugfixes oder Hotfixes. Im Regelfall werden bei diesen Lösungen nur Fehlerbeseitigungen berücksichtigt, ohne neue Funktionen zu integrieren.
Minor Release
Mit dem Minor Release werden kleinere Veränderungen oder Erweiterungen an einer bereits vorhandenen Version vorgenommen. Mitunter kann der Minor Release einen Emergency Fix ersetzen.
Major Release
Der Major Release umfasst einschneidende Neuerungen bei einer Software oder einem Produkt. Bestimmte Funktionsbereiche werden erstmalig unterstützt. Diese Erneuerungen gehen meist mit Änderungen an der System- und IT-Infrastruktur einher.
Der Major Release ersetzt den Minor und den Emergency Release und macht zum Beispiel Bugfixes überflüssig.
Welche Branchen nutzen Releases?
Releases, die Herausgabe neuer Produkte oder Produktversionen, finden in vielen unterschiedlichen Bereichen statt. Dabei muss es sich nicht immer um die Veröffentlichung neuer Softwareprogramme in der IT-Branche drehen. Der Begriff wird ebenso von anderen Branchen genutzt. Dazu zählen zum Beispiel:
- Das Loslassen einer Taste bei einem elektronischen Tasteninstrument wird mit der Release Velocity definiert.
- Die Ausschüttung von Botenstoffen in der Pharmakologie.
- Die Vermarktung und Publizierung neuer CDs, Kinofilme oder Bücher. Hier werden für Marketing- und Werbezwecke pompöse Parties veranstaltet.
- Die Modellpflege von Fahrzeugreihen in der Automobilindustrie.
Der Begriff wird folglich in vielen verschiedenen Bereichen genutzt. Doch immer dreht es sich um Änderungen, Verbesserungen oder um komplette Neuerscheinungen eines bestimmten Produktes.
Wie funktioniert der Prozess des Release Managements?
Hält der Verbraucher ein neues Softwareprogramm in Händen, so ist dies das Ergebnis von vielen Prozessen, die dank des Release Management aufeinander abgestimmt und koordiniert werden. Dabei können Sie auf die Unterstützung von Experten vertrauen, die den Entwicklungsprozess begleiten und als Ratgeber fungieren, um den Prozess in Gang zu bringen.
In welcher Weise die notwendigen Schritte abgehandelt werden und wie viel Zeit jeder Schritt in Anspruch nimmt, hängt dabei von den spezifischen Anforderungen des Unternehmens ab. Folgende Schritte werden in der Regel abgehandelt:
Anfrage
Bevor das Release Management in Aktion tritt, muss eine Anfrage nach Änderungen oder zusätzlichen Funktionen gestellt worden sein. Die eingehenden Anfragen werden zunächst geprüft. Begründbarkeit und Realisierbarkeit werden hier betrachtet. Zusätzlich wird versucht, das vorhandene Problem mit bereits existierenden Funktionen des Programms zu lösen.
Planung
In dieser Phase wird die Struktur des Release festgelegt. Es wird entschieden, welche Release-Komponenten integriert werden sollten und wie die Durchführung stattfindet. Hier lohnt es, sich an Prozessen und Abläufen vorangegangener Releases zu orientieren. Das spart meist einiges an Ressourcen.
Aufgaben und Verantwortlichkeiten werden innerhalb der IT-Abteilung verteilt.
Entwurf
Alle Anforderungen werden in diesem Schritt des Release-Management-Prozesses in das eigentliche Programm übertragen. Hier findet die Entwicklung und die Übersetzung in Codes statt.
Testphase
Ist die nächste Phase erreicht, wird vom Release Manager die erste Testumgebung vorbereitet. Das neue Produkt wird in diese Umgebung integriert und funktionalen und nicht-funktionalen Tests unterzogen.
Stoßen die Tester auf Fehler und Bugs, muss das Produkt zurück in die IT-Abteilung zu den Entwicklern. Diese Phase kann einige Zeit in Anspruch nehmen, je nachdem, wie viele Bugs und Fehler auftauchen.
Integration
Die folgende Phase des Release-Management-Prozesses ist die Integration in die echte Arbeitsumgebung. Dabei reicht es nicht aus, dass neue Produkte einfach installiert werden, es muss auch eine Schulung der Mitarbeiter stattfinden. Auf diese Weise wird eine schnelle Umstellung auf das neue Produkt garantiert.
Was beinhaltet das Release Package, welches Problem wurde behoben und mit welchen zusätzlichen Funktionen werden die Anforderungen umgesetzt? Über all diese Punkte sollte an dieser Stelle informiert werden.
Post-Deployment
Post-Deployment, also der Support nach dem Release, muss bei einer guten Planung immer berücksichtigt werden. Jetzt heißt es, den Nutzern als Support zur Verfügung zu stehen und das Auftreten von Bugs zu registrieren. Gegebenenfalls müssen erneut Änderungen in Auftrag gegeben werden.
Post-Deployment wird in zwei Abschnitte unterteilt: den Early Life Support und den Release-Abschluss. Sind alle möglichen Probleme in der Startphase behoben, wird der Release offiziell als abgeschlossen betrachtet.
Funktionsweise des Release Management mit ITIL
ITIL-Framework ist ein Tool, das für Release-Management-Prozesse eingesetzt wird. ITIL (Information Technology Infrastructure Library) unterstützt Unternehmen bei der Kontrolle von Qualität und Kosten, außerdem verfügt es über eine nutzerfreundliche Bedienoberfläche.
Alle Release-Aktivitäten, die zum Rollout eines neuen Produktes gehören, können mit ITIL-Framework überwacht und koordiniert werden. Planung, Konzeption, Testphase und die Durchführung des eigentlichen Rollout zählen dazu.
In übersichtlichen Diagrammen werden die wichtigsten Schnittstellen im Release-Management-Prozess dargestellt. Konfiguration Management, Change Management und die unterschiedlichen Release-Komponenten werden auf dieser Plattform organisiert.
Je nach Größe des Unternehmens und des IT-Service-Management wird einige Zeit in Anspruch genommen, wenn zum Beispiel die komplette IT-Infrastruktur einer Firma auf ein neues System umgestellt wird. Minor Releases oder Emergency Fixes nehmen meist relativ wenig Zeit in Anspruch.
Woran erkennen Sie ein erfolgreiches Release Management?
Ein gutes Releasemanagement wird an folgenden Punkten sichtbar:
- Das Budget der Bereitstellungskosten wird nicht überschritten.
- Die neuen IT Services werden pünktlich übergeben.
- Der Release-Prozess hat nur wenig oder gar keine Auswirkungen auf den Workflow der Kunden.
- Alle Anforderungen werden erfüllt und neue als auch bereits bestehende Nutzer können die neue IT-Umgebung ohne Probleme nutzen.
Release Management versus Enterprise Release Management
Das Release Management im IT-Sektor erfüllt eine begleitende organisatorische Funktion, die von einem Release Manager überwacht wird. Dieser koordiniert die unterschiedlichen Prozesse des Entwicklungszyklus, die von der Anfrage über Design bis hin zur Durchführung und zum Release, zur Veröffentlichung, reichen.
Bei großen Unternehmen bezeichnet das Enterprise Release Management die Spezialisten im Haus, die sich um die IT-Infrastruktur kümmern. Hier werden die technischen Voraussetzungen der Unternehmen mit den gewünschten Systemen abgeglichen und mitunter sehr komplexe neue Systeme installiert. Die Synchronisierung unterschiedlicher Releases von mehr als einem Softwareentwickler kann durchaus Monate dauern.
Das Enterprise Release Management achtet darauf, dass die Workflows des Tagesgeschäftes nicht unterbrochen werden. Muss eine Produktionslinie wegen Aktualisierungsmaßnahmen außerplanmäßig stillgelegt werden, entstehen mitunter sehr große Umsatzeinbußen für die produzierende Industrie. Produktmanagement und Change-Management werden vom ERM überwacht, welches ebenfalls die Qualitätskontrolle übernimmt.
Rolle des Release Management in IT-Umgebungen
Release Management wird eine immer größere Bedeutung zugesprochen, bauen doch viele Unternehmen auf IT-Lösungen auf. Fast kein Unternehmen, das sich auf dem Markt beweisen möchte, kommt ohne Softwareprogramme aus. Mittlere bis große Firmen organisieren ganze Produktionslinien digital. Die Verwaltung und der Entwurf neuer Produkte erfolgt immer zu einem gewissen Teil mit digitalen Tools.
Bei Änderungen, Aktualisierungen oder bei der Umstellung der IT-Landschaft muss ein Zeitplan mit allen Involvierten erarbeitet werden, um Produktionsumgebungen so wenig wie möglich zu beeinflussen. Diese Koordination übernimmt der Release Manager.
Bietet ein Unternehmen selbst Releases für eine neue IT-Lösung an, so koordiniert hier der Release Manager den kompletten Entwicklungsprozess von der Idee bis hin zum Rollout. Bereits vor der Veröffentlichung, also dem Rollout, wird das Marketing aktiv. Mit Newsletter, Werbebanner oder -spot werden Benutzer auf ein neues Versionspaket aufmerksam gemacht.
Diese Kampagnen können intern entwickelt werden oder von einer Agentur, die sich auf dieses Metier spezialisiert hat. Release Management kann entsprechend bei großen Firmen eine eigene Abteilung bilden. Kleinere Betriebe nutzen vielleicht lieber den Dienst Dritter, wenn Bedarf besteht. In allen Fällen sorgt ein gut organisiertes Release Management für aktualisierte Produktionsumgebungen mit optimalen Arbeitsbedingungen.
