5.4 Release Management und Deployment Management

Kurz erklärt 
 Release Management und Deployment Management sorgen dafür, dass neue oder geänderte Services, Anwendungen, Funktionen oder Infrastrukturkomponenten kontrolliert bereitgestellt werden. 
 Release Management betrachtet vor allem, wann und in welcher Form eine Änderung für Benutzer oder Kunden verfügbar gemacht wird. 
 Deployment Management betrachtet vor allem, wie technische Komponenten in eine Zielumgebung gebracht werden. 
 Beide Bereiche hängen eng mit Change Enablement zusammen. 
 
 
 Warum Release und Deployment wichtig sind 
 Viele Änderungen werden nicht einzeln sichtbar. 
 Oft werden mehrere technische Änderungen gemeinsam bereitgestellt. 
 Beispiele: 
 
 neue Anwendungsversion, 
 Sicherheitsupdate, 
 neue Funktion im Serviceportal, 
 neue VPN-Client-Version, 
 aktualisierte Serverkonfiguration, 
 geänderte Schnittstelle, 
 neues Monitoring, 
 neue Self-Service-Funktion, 
 aktualisiertes Berechtigungskonzept. 
 
 Wenn solche Änderungen unkoordiniert ausgerollt werden, können entstehen: 
 
 Incidents nach Updates, 
 Benutzerverwirrung, 
 fehlende Dokumentation, 
 inkompatible Versionen, 
 unklare Verantwortlichkeiten, 
 fehlende Rollback-Möglichkeiten, 
 nicht informierter Service Desk, 
 und unnötige Störungen im Betrieb. 
 
 Release und Deployment sorgen für geordnete Bereitstellung. 
 
 Release und Deployment unterscheiden 
 
 
 
 Begriff 
 Bedeutung 
 
 
 
 
 Release 
 Bündel neuer oder geänderter Funktionen, Services oder Komponenten, das bereitgestellt und für Nutzung freigegeben wird 
 
 
 Deployment 
 technische Überführung von Komponenten in eine Zielumgebung 
 
 
 Change 
 kontrollierte Änderung an einem Service oder unterstützenden Bestandteil 
 
 
 Rollout 
 Verteilung oder Einführung eines Releases bei Benutzern, Standorten oder Systemen 
 
 
 Rollback 
 Rücknahme einer Änderung auf einen vorherigen Zustand 
 
 
 Backout 
 geplanter Ausstieg aus einer Änderung, wenn Abbruchkriterien erfüllt sind 
 
 
 
 Ein Deployment kann technisch erfolgreich sein, obwohl das Release aus Benutzersicht noch nicht erfolgreich ist. 
 Beispiel: 
 Die neue Version wurde auf dem Server installiert. 
 Benutzer können aber eine wichtige Funktion nicht nutzen. 
 Technisch wurde deployed. 
 Das Release ist fachlich noch nicht erfolgreich. 
 
 Release Management 
 Release Management plant, koordiniert und steuert die Bereitstellung neuer oder geänderter Services und Funktionen. 
 Typische Fragen: 
 
 Was wird veröffentlicht? 
 Welche Funktionen oder Änderungen sind enthalten? 
 Welche Benutzer oder Kunden sind betroffen? 
 Wann wird das Release verfügbar? 
 Welche Kommunikation ist notwendig? 
 Welche Dokumentation muss aktualisiert werden? 
 Welche Risiken bestehen? 
 Welche Abhängigkeiten gibt es? 
 Welche Changes gehören zum Release? 
 Wie wird der Erfolg geprüft? 
 
 Release Management verbindet technische Bereitstellung mit Benutzer- und Serviceperspektive. 
 
 Deployment Management 
 Deployment Management sorgt dafür, dass technische Komponenten kontrolliert in eine Zielumgebung gebracht werden. 
 Typische Fragen: 
 
 Welche Komponenten werden installiert oder geändert? 
 In welche Umgebung wird deployed? 
 Welche Version wird bereitgestellt? 
 Welche Reihenfolge ist notwendig? 
 Welche Abhängigkeiten bestehen? 
 Welche Tests sind erforderlich? 
 Wie wird der technische Zustand geprüft? 
 Wie wird zurückgerollt? 
 Welche Automatisierung wird genutzt? 
 Welche Logs und Nachweise entstehen? 
 
 Deployment Management besitzt damit einen stärker technischen Fokus. 
 
 Release, Deployment und Change Enablement im Zusammenspiel 
 Ein möglicher Zusammenhang: 
 Änderungsbedarf entsteht
 ↓
Change Request wird erstellt
 ↓
Risiko und Auswirkung werden bewertet
 ↓
Release wird geplant
 ↓
Deployment wird vorbereitet
 ↓
Change wird genehmigt
 ↓
Deployment wird durchgeführt
 ↓
Release wird für Benutzer verfügbar
 ↓
Erfolg wird geprüft
 ↓
Dokumentation und Knowledge werden aktualisiert
 
 Nicht jede Organisation trennt diese Schritte gleich stark. 
 Wichtig ist, dass technische Umsetzung, Freigabe und Kommunikation zusammenpassen. 
 
 Beispiel: Anwendungsversion 
 Eine Fachanwendung erhält eine neue Version. 
 Change Enablement 
 
 bewertet Risiko, 
 prüft Freigabe, 
 legt Wartungsfenster fest, 
 betrachtet Rollback und Kommunikation. 
 
 Release Management 
 
 plant, welche Version wann veröffentlicht wird, 
 klärt enthaltene Funktionen, 
 informiert Benutzer und Service Desk, 
 stellt Release Notes bereit. 
 
 Deployment Management 
 
 installiert die neue Version, 
 führt technische Prüfschritte aus, 
 kontrolliert Logs und Monitoring, 
 stellt bei Bedarf zurück. 
 
 Alle drei Bereiche müssen zusammenarbeiten. 
 
 Release-Paket 
 Ein Release-Paket kann alle Bestandteile enthalten, die für eine Bereitstellung notwendig sind. 
 Mögliche Inhalte: 
 
 Anwendungsversion, 
 Konfigurationsdateien, 
 Datenbankskripte, 
 Infrastrukturänderungen, 
 Installationsanleitung, 
 Testnachweise, 
 Rollback-Anleitung, 
 Release Notes, 
 Benutzerinformation, 
 aktualisierte Knowledge-Artikel, 
 Monitoring-Anpassungen, 
 Sicherheitsfreigaben, 
 Change-Verknüpfungen. 
 
 Nicht jedes Release-Paket ist gleich umfangreich. 
 Der Umfang muss zum Risiko und zur Bedeutung des Releases passen. 
 
 Release-Plan 
 Ein Release-Plan beschreibt, wann und wie ein Release bereitgestellt wird. 
 Typische Inhalte: 
 
 Release-Name oder Version, 
 betroffene Services, 
 enthaltene Changes, 
 Zielumgebungen, 
 geplanter Zeitraum, 
 beteiligte Teams, 
 Abhängigkeiten, 
 Kommunikationsmaßnahmen, 
 Teststrategie, 
 Deployment-Schritte, 
 Rollback-Plan, 
 Erfolgskriterien, 
 Verantwortlichkeiten. 
 
 Ein Release-Plan muss nicht kompliziert sein. 
 Er muss aber ausreichend klar sein, damit alle Beteiligten wissen, was passiert. 
 
 Release Notes 
 Release Notes beschreiben, was sich mit einem Release ändert. 
 Sie können enthalten: 
 
 neue Funktionen, 
 geänderte Funktionen, 
 behobene Fehler, 
 bekannte Einschränkungen, 
 bekannte Fehler, 
 Workarounds, 
 betroffene Benutzergruppen, 
 notwendige Benutzeraktionen, 
 geänderte Systemanforderungen, 
 Ansprechpartner oder Supportweg. 
 
 Release Notes sollten zielgruppengerecht sein. 
 Technische Teams benötigen andere Informationen als Endbenutzer. 
 
 Benutzerorientierte Release Notes 
 Ungeeignet: 
 
 Backend-Komponente API-GW-PRD wurde auf Build 2026.08.14-rc3 aktualisiert. 
 
 Besser: 
 
 Die Suche im Mitarbeiterportal wurde verbessert. Ergebnisse werden nun schneller angezeigt. Während des Updates kann das Portal am 14.08.2026 zwischen 20:00 und 20:30 Uhr kurzzeitig nicht verfügbar sein. 
 
 Benutzer müssen verstehen: 
 
 Was ändert sich für mich? 
 Wann passiert es? 
 Muss ich etwas tun? 
 Wo bekomme ich Hilfe? 
 
 
 Deployment-Plan 
 Ein Deployment-Plan beschreibt die technische Umsetzung. 
 Mögliche Inhalte: 
 
 Zielumgebung, 
 Version, 
 betroffene Komponenten, 
 Reihenfolge der Schritte, 
 Verantwortliche, 
 benötigte Berechtigungen, 
 benötigte Dateien oder Images, 
 Vorbereitungsaufgaben, 
 technische Prüfschritte, 
 Monitoring, 
 Abbruchkriterien, 
 Rollback-Schritte, 
 Dokumentationshinweise. 
 
 Bei einfachen Deployments kann der Plan kurz sein. 
 Bei kritischen Deployments muss er detaillierter sein. 
 
 Umgebungen 
 Viele Organisationen nutzen mehrere Umgebungen. 
 Beispiele: 
 
 Entwicklung, 
 Test, 
 Integration, 
 Abnahme, 
 Staging, 
 Produktion. 
 
 Ziel ist, Änderungen vor der Produktion zu prüfen. 
 Typische Fragen: 
 
 Entspricht die Testumgebung der Produktion ausreichend? 
 Sind Testdaten geeignet? 
 Sind Schnittstellen realistisch abgebildet? 
 Sind Berechtigungen vergleichbar? 
 Wurden Konfigurationen korrekt übernommen? 
 Sind Unterschiede zwischen Umgebungen dokumentiert? 
 
 Ein Test in einer völlig abweichenden Umgebung gibt nur begrenzte Sicherheit. 
 
 Test und Abnahme 
 Vor einem Release sollten geeignete Tests durchgeführt werden. 
 Mögliche Tests: 
 
 Funktionstest, 
 Integrationstest, 
 Sicherheitstest, 
 Performance-Test, 
 Regressionstest, 
 Benutzerakzeptanztest, 
 Smoke Test, 
 Wiederherstellungstest, 
 Monitoringtest. 
 
 Der Testumfang hängt vom Risiko ab. 
 Ein kritisches Release benötigt mehr Prüfung als eine kleine, risikoarme Änderung. 
 
 Regressionstest 
 Ein Regressionstest prüft, ob bestehende Funktionen nach einer Änderung weiterhin funktionieren. 
 Beispiel: 
 Eine neue Exportfunktion wird eingebaut. 
 Der Regressionstest prüft zusätzlich: 
 
 Anmeldung, 
 Suche, 
 Speichern, 
 bestehender Export, 
 Berechtigungen, 
 Schnittstellen. 
 
 Dadurch wird verhindert, dass eine neue Funktion alte Funktionen unbeabsichtigt beschädigt. 
 
 Smoke Test nach Deployment 
 Ein Smoke Test ist eine kurze Grundprüfung direkt nach dem Deployment. 
 Beispiele: 
 
 Service startet, 
 Anmeldung funktioniert, 
 Startseite lädt, 
 Datenbankverbindung steht, 
 Schnittstelle antwortet, 
 Monitoring zeigt keine kritischen Alarme, 
 zentrale Benutzeraktion funktioniert. 
 
 Ein Smoke Test ersetzt keine vollständige Abnahme. 
 Er hilft aber, grobe Fehler sofort zu erkennen. 
 
 Deployment-Methoden 
 Organisationen können verschiedene Deployment-Methoden nutzen. 
 Beispiele: 
 
 
 
 Methode 
 Kurzbeschreibung 
 
 
 
 
 Big Bang 
 Bereitstellung für alle Benutzer gleichzeitig 
 
 
 phasenweise Bereitstellung 
 Einführung in mehreren Gruppen oder Standorten 
 
 
 Pilot 
 begrenzte Einführung bei kleiner Benutzergruppe 
 
 
 Rolling Deployment 
 schrittweise Aktualisierung einzelner Systeme 
 
 
 Blue-Green Deployment 
 Wechsel zwischen zwei vorbereiteten Umgebungen 
 
 
 Canary Deployment 
 neue Version zunächst für kleinen Teil der Benutzer 
 
 
 Feature Toggle 
 Funktion wird technisch bereitgestellt, aber gezielt aktiviert oder deaktiviert 
 
 
 
 Diese Methoden sind Praxisbeispiele. 
 ITIL schreibt keine bestimmte technische Deployment-Methode für alle Organisationen vor. 
 
 Big-Bang-Deployment 
 Beim Big-Bang-Deployment wird eine Änderung für alle betroffenen Benutzer oder Systeme gleichzeitig bereitgestellt. 
 Vorteile: 
 
 einfacher Zeitplan, 
 keine parallelen Versionen, 
 schnelle vollständige Einführung. 
 
 Risiken: 
 
 Fehler betreffen sofort alle Benutzer, 
 hoher Kommunikationsbedarf, 
 Rollback kann kritisch sein, 
 Supportspitzen möglich. 
 
 Geeignet eher dann, wenn: 
 
 Risiko überschaubar ist, 
 Testqualität hoch ist, 
 Rollback möglich ist, 
 und alle Benutzer gleichzeitig wechseln müssen. 
 
 
 Phasenweise Bereitstellung 
 Bei einer phasenweisen Bereitstellung erfolgt der Rollout schrittweise. 
 Beispiele: 
 
 zuerst IT-Team, 
 dann Pilotgruppe, 
 dann ein Standort, 
 dann alle Standorte, 
 dann externe Benutzer. 
 
 Vorteile: 
 
 Fehler werden früher erkannt, 
 Auswirkungen bleiben zunächst begrenzt, 
 Support kann Erfahrungen sammeln, 
 Kommunikation kann angepasst werden. 
 
 Risiken: 
 
 mehrere Versionen parallel, 
 längere Gesamtdauer, 
 zusätzlicher Koordinationsaufwand. 
 
 
 Pilot 
 Ein Pilot testet ein Release mit einer begrenzten Benutzergruppe. 
 Geeignet für: 
 
 neue Software, 
 neue Geräte, 
 neue Prozesse, 
 größere Updates, 
 Änderungen mit Benutzerwirkung. 
 
 Ein Pilot sollte klare Kriterien besitzen: 
 
 Wer nimmt teil? 
 Welche Funktionen werden getestet? 
 Wie wird Feedback gesammelt? 
 Wann ist der Pilot erfolgreich? 
 Wann wird gestoppt? 
 Was passiert nach dem Pilot? 
 
 Ein Pilot ohne Auswertung bringt wenig Nutzen. 
 
 Blue-Green Deployment 
 Beim Blue-Green Deployment existieren zwei Umgebungen. 
 Beispiel: 
 
 Blau = aktuelle produktive Umgebung, 
 Grün = neue vorbereitete Umgebung. 
 
 Nach Tests wird der Verkehr auf die neue Umgebung umgeschaltet. 
 Vorteile: 
 
 schneller Wechsel möglich, 
 Rollback kann einfacher sein, 
 neue Umgebung kann vorbereitet werden. 
 
 Risiken: 
 
 höhere Infrastrukturkosten, 
 Datenbank- und Datenkonsistenz beachten, 
 Umschaltung muss sauber getestet sein, 
 nicht für jede Architektur geeignet. 
 
 
 Canary Deployment 
 Beim Canary Deployment erhält zuerst nur ein kleiner Teil der Benutzer die neue Version. 
 Wenn keine Probleme auftreten, wird der Anteil erhöht. 
 Vorteile: 
 
 Risiko wird begrenzt, 
 echte Nutzung liefert frühe Signale, 
 Fehler betreffen zunächst wenige Benutzer. 
 
 Risiken: 
 
 Monitoring muss gut sein, 
 Benutzergruppen müssen steuerbar sein, 
 parallele Versionen können komplex sein, 
 Support muss wissen, wer welche Version nutzt. 
 
 
 Feature Toggles 
 Feature Toggles ermöglichen, Funktionen unabhängig vom technischen Deployment zu aktivieren oder zu deaktivieren. 
 Beispiel: 
 Die neue Funktion ist bereits deployed, aber nur für eine Pilotgruppe aktiviert. 
 Vorteile: 
 
 kontrollierte Freigabe, 
 schnelles Deaktivieren bei Problemen, 
 Trennung von Deployment und Release möglich. 
 
 Risiken: 
 
 zusätzliche Komplexität, 
 alte Schalter werden vergessen, 
 Tests werden schwieriger, 
 falsche Aktivierung kann Incidents erzeugen. 
 
 Feature Toggles benötigen klare Verwaltung und Dokumentation. 
 
 Deployment-Automatisierung 
 Deployments werden häufig automatisiert. 
 Beispiele: 
 
 Softwareverteilung, 
 CI/CD-Pipeline, 
 Skripte, 
 Container-Deployment, 
 Infrastruktur als Code, 
 Konfigurationsmanagement, 
 Paketverteilung, 
 Cloud-Automatisierung. 
 
 Vorteile: 
 
 reproduzierbar, 
 schneller, 
 weniger manuelle Fehler, 
 besser protokollierbar, 
 leichter wiederholbar. 
 
 Risiken: 
 
 falsche Automatisierung skaliert Fehler schnell, 
 Berechtigungen können zu weit sein, 
 Rollback muss ebenfalls berücksichtigt werden, 
 Tests müssen zuverlässig sein, 
 Pipeline-Ausfälle können Deployments blockieren. 
 
 
 Manuelles Deployment 
 Manuelle Deployments können notwendig sein, wenn: 
 
 Umgebung sehr speziell ist, 
 Automatisierung noch nicht vorhanden ist, 
 Änderung einmalig ist, 
 Risiko eine bewusste Schritt-für-Schritt-Kontrolle erfordert. 
 
 Risiken manueller Deployments: 
 
 Tippfehler, 
 vergessene Schritte, 
 unterschiedliche Durchführung, 
 schlechte Reproduzierbarkeit, 
 fehlende Protokollierung. 
 
 Runbooks und Checklisten reduzieren diese Risiken. 
 
 Release-Kalender 
 Ein Release-Kalender zeigt geplante Releases und wichtige Change-Zeitpunkte. 
 Er hilft bei: 
 
 Koordination, 
 Vermeidung von Überschneidungen, 
 Kommunikation, 
 Ressourcenplanung, 
 Wartungsfenstern, 
 Change Freeze, 
 Lieferantenabstimmung, 
 Bereitschaftsplanung. 
 
 Ein Release-Kalender sollte für relevante Teams sichtbar sein. 
 
 Change Freeze und Release Freeze 
 Ein Freeze ist ein Zeitraum, in dem Releases oder Changes eingeschränkt werden. 
 Beispiele: 
 
 Jahresabschluss, 
 Feiertagsgeschäft, 
 Produktionshochlauf, 
 Auditphase, 
 Prüfungszeitraum, 
 große Migration. 
 
 Ein Freeze bedeutet nicht zwingend, dass gar nichts geändert werden darf. 
 Sicherheitsupdates oder Emergency Changes können trotzdem notwendig sein. 
 Dann muss besonders bewusst entschieden und dokumentiert werden. 
 
 Kommunikation vor einem Release 
 Vor einem Release sollten betroffene Gruppen informiert werden. 
 Mögliche Inhalte: 
 
 was sich ändert, 
 wann es sich ändert, 
 welche Services betroffen sind, 
 ob Ausfallzeiten entstehen, 
 welche neuen Funktionen verfügbar sind, 
 welche bekannten Einschränkungen bestehen, 
 was Benutzer tun müssen, 
 wo Hilfe verfügbar ist, 
 wann die nächste Information folgt. 
 
 Der Service Desk muss besonders gut vorbereitet sein. 
 
 Service Desk vorbereiten 
 Der Service Desk benötigt vor einem Release: 
 
 Release Notes, 
 bekannte Fehler, 
 Workarounds, 
 Supportskripte, 
 Eskalationswege, 
 betroffene Benutzergruppen, 
 geplante Ausfallzeiten, 
 Ansprechpartner, 
 Statusinformationen, 
 Knowledge-Artikel. 
 
 Ohne Vorbereitung steigen nach einem Release unnötige Tickets und Rückfragen. 
 
 Monitoring während und nach Deployment 
 Während und nach einem Deployment sollte Monitoring aktiv beobachtet werden. 
 Zu prüfen sind: 
 
 Verfügbarkeit, 
 Antwortzeiten, 
 Fehlerraten, 
 CPU und Arbeitsspeicher, 
 Datenbankverbindungen, 
 Schnittstellen, 
 Warteschlangen, 
 Logfehler, 
 Sicherheitsmeldungen, 
 Benutzeranmeldungen, 
 Ticketaufkommen. 
 
 Nach kritischen Releases kann eine verstärkte Beobachtungsphase sinnvoll sein. 
 
 Rollback und Roll Forward 
 Bei Problemen nach einem Deployment gibt es zwei grundsätzliche Richtungen. 
 
 
 
 Ansatz 
 Bedeutung 
 
 
 
 
 Rollback 
 Rückkehr zum vorherigen Zustand 
 
 
 Roll Forward 
 Vorwärtskorrektur durch neue Änderung oder Hotfix 
 
 
 
 Rollback ist nicht immer möglich. 
 Roll Forward kann sinnvoll sein, wenn: 
 
 Daten bereits migriert wurden, 
 Rückkehr zu riskant wäre, 
 Fehler schnell korrigierbar ist, 
 neue Version nur kleine Korrektur benötigt. 
 
 Beide Wege benötigen Entscheidung, Dokumentation und Risikobewertung. 
 
 Release-Erfolg prüfen 
 Nach einem Release sollte geprüft werden: 
 
 Wurde das Release wie geplant bereitgestellt? 
 Funktionieren Kernservices? 
 Sind Benutzer arbeitsfähig? 
 Sind Incidents nach dem Release entstanden? 
 Wurden erwartete Funktionen geliefert? 
 Sind bekannte Fehler dokumentiert? 
 Wurde der Service Desk informiert? 
 Sind Monitoring und Logs unauffällig? 
 Muss Knowledge aktualisiert werden? 
 Wurde der erwartete Nutzen erreicht? 
 
 Ein Release ist nicht erfolgreich, nur weil Dateien deployed wurden. 
 Es muss aus Service- und Benutzersicht funktionieren. 
 
 Post-Deployment Review 
 Ein Post-Deployment Review kann nach wichtigen Deployments sinnvoll sein. 
 Fragen: 
 
 Was lief gut? 
 Was lief anders als geplant? 
 Waren Tests ausreichend? 
 War Kommunikation ausreichend? 
 Gab es Incidents? 
 War Rollback realistisch? 
 Waren Abhängigkeiten bekannt? 
 War die Automatisierung zuverlässig? 
 Muss das Runbook verbessert werden? 
 Welche Lessons Learned gibt es? 
 
 Nicht jedes kleine Deployment benötigt ein ausführliches Review. 
 Bei kritischen oder fehlgeschlagenen Deployments ist es wichtig. 
 
 Release Management und Knowledge Management 
 Nach einem Release müssen Wissensbestände aktualisiert werden. 
 Mögliche Inhalte: 
 
 Benutzeranleitungen, 
 Service-Desk-Artikel, 
 Known Errors, 
 Workarounds, 
 Runbooks, 
 FAQ, 
 Screenshots, 
 Menüpfade, 
 Installationsanleitungen, 
 Monitoringhinweise, 
 Eskalationswege. 
 
 Veraltete Knowledge-Artikel erzeugen nach Releases häufig neue Tickets. 
 
 Release Management und Configuration Management 
 Nach Releases und Deployments müssen Configuration Items aktuell bleiben. 
 Mögliche Änderungen: 
 
 neue Version, 
 neue Komponente, 
 geänderte Schnittstelle, 
 geänderte Abhängigkeit, 
 neuer Server, 
 neues Zertifikat, 
 geänderte Konfiguration, 
 neuer Owner, 
 geänderter Lieferant. 
 
 Wenn die CMDB veraltet bleibt, werden spätere Incidents, Problems und Changes schwieriger. 
 
 Release Management und Incident Management 
 Nach Releases können Incidents entstehen. 
 Deshalb sollte Incident Management vorbereitet sein. 
 Wichtig: 
 
 Release-Zeitpunkt kennen, 
 bekannte Änderungen kennen, 
 betroffene Services erkennen, 
 typische Symptome kennen, 
 Known Errors nutzen, 
 Eskalationswege kennen, 
 Release-Team erreichbar haben. 
 
 Ein Anstieg von Incidents nach einem Release kann auf Probleme in Test, Kommunikation oder Deployment hinweisen. 
 
 Release Management und Problem Management 
 Wenn nach einem Release wiederkehrende oder schwere Incidents entstehen, kann ein Problem Record notwendig sein. 
 Problem Management prüft dann: 
 
 War das Release Ursache oder Auslöser? 
 Welche Funktion ist betroffen? 
 Warum wurde der Fehler im Test nicht erkannt? 
 Welche Abhängigkeit war unbekannt? 
 Welche Benutzergruppe ist betroffen? 
 Gibt es einen Workaround? 
 Ist Rollback oder Roll Forward sinnvoll? 
 Welche dauerhafte Lösung wird benötigt? 
 
 
 Release Management und Change Enablement 
 Change Enablement sorgt dafür, dass Releases und Deployments kontrolliert umgesetzt werden. 
 Zu klären ist: 
 
 Welche Changes gehören zum Release? 
 Welche Freigaben sind notwendig? 
 Welche Risiken bestehen? 
 Sind Wartungsfenster abgestimmt? 
 Gibt es parallele Changes? 
 Gibt es ein Rollback? 
 Ist Kommunikation vorbereitet? 
 Wurde der Erfolg geprüft? 
 
 Release und Deployment sollten nicht an Change Enablement vorbei erfolgen. 
 
 Praxisbeispiel: VPN-Client-Rollout 
 Ausgangslage 
 Eine alte VPN-Client-Version verursacht wiederkehrende Incidents. 
 Release 
 Neue VPN-Client-Version wird bereitgestellt. 
 Deployment 
 
 Pilotgruppe erhält neue Version, 
 Logs und Verbindungsstabilität werden geprüft, 
 Service Desk erhält Workaround und Eskalationshinweise, 
 anschließend phasenweiser Rollout an alle Notebooks. 
 
 Erfolgskontrolle 
 VPN-Incidents gehen zurück. 
 Known Error wird aktualisiert. 
 Knowledge-Artikel wird angepasst. 
 
 Praxisbeispiel: Mitarbeiterportal 
 Ausgangslage 
 Das Mitarbeiterportal erhält neue Funktionen. 
 Release Management 
 
 Release Notes erstellen, 
 Benutzerinformation vorbereiten, 
 Fachbereich einbinden, 
 Service Desk briefen. 
 
 Deployment Management 
 
 neue Version im Wartungsfenster installieren, 
 Datenbankskripte ausführen, 
 Smoke Test durchführen, 
 Monitoring prüfen. 
 
 Nachbereitung 
 Incidents nach Release beobachten und Knowledge-Artikel aktualisieren. 
 
 Praxisbeispiel: Fehlgeschlagenes Deployment 
 Situation 
 Eine neue Anwendungsversion wird erfolgreich installiert. 
 Problem 
 Nach dem Deployment funktioniert der PDF-Export nicht mehr. 
 Maßnahmen 
 
 Incident erstellen, 
 Fachbereich informieren, 
 Rollback oder Hotfix bewerten, 
 Problem Record bei wiederkehrendem Fehler prüfen, 
 Testplan erweitern, 
 Release Notes und Known Errors aktualisieren. 
 
 Lerneffekt 
 Der Testplan muss künftig auch Exportfunktionen abdecken. 
 
 Typische Fehler 
 Fehler 1 
 Release und Deployment werden gleichgesetzt. 
 
 Fehler 2 
 Technisches Deployment gelingt, aber Benutzer sind nicht vorbereitet. 
 
 Fehler 3 
 Service Desk erhält keine Release-Informationen. 
 
 Fehler 4 
 Release Notes fehlen oder sind zu technisch. 
 
 Fehler 5 
 Tests decken wichtige Geschäftsprozesse nicht ab. 
 
 Fehler 6 
 Rollback wird nicht realistisch geplant. 
 
 Fehler 7 
 Mehrere Releases kollidieren zeitlich. 
 
 Fehler 8 
 Monitoring wird nach Deployment nicht beobachtet. 
 
 Fehler 9 
 Known Errors und Workarounds werden nicht dokumentiert. 
 
 Fehler 10 
 CMDB und Knowledge Base bleiben nach Release veraltet. 
 
 Fehler 11 
 Fehlgeschlagene Deployments werden nicht ausgewertet. 
 
 Fehler 12 
 Automatisierung wird genutzt, aber nicht überwacht. 
 
 Checkliste Release Management 
 
 Release-Inhalt ist beschrieben 
 betroffene Services sind bekannt 
 betroffene Benutzergruppen sind bekannt 
 enthaltene Changes sind verknüpft 
 Risiken sind bewertet 
 Release Notes sind vorbereitet 
 Service Desk ist informiert 
 Kommunikationsplan ist vorhanden 
 Testnachweise liegen vor 
 Known Errors sind dokumentiert 
 Erfolgskriterien sind definiert 
 Nachbeobachtung ist geplant 
 
 
 Checkliste Deployment Management 
 
 Zielumgebung ist bekannt 
 Version ist eindeutig 
 Komponenten sind vollständig 
 Deployment-Schritte sind dokumentiert 
 Berechtigungen sind vorhanden 
 Backups oder Sicherungen sind geprüft 
 Rollback oder Roll Forward ist bewertet 
 Abbruchkriterien sind definiert 
 Monitoring ist aktiv 
 Smoke Test ist definiert 
 Ergebnis wird dokumentiert 
 Abweichungen werden erfasst 
 
 
 Checkliste Kommunikation 
 
 Benutzerinformation vorbereitet 
 Service Desk informiert 
 Fachbereiche informiert 
 Management informiert, falls relevant 
 Lieferanten eingebunden, falls relevant 
 Ausfallzeit klar benannt 
 neue Funktionen verständlich erklärt 
 bekannte Einschränkungen genannt 
 Supportweg beschrieben 
 Abschlussmeldung vorgesehen 
 
 
 Checkliste Nachbereitung 
 
 Release-Erfolg geprüft 
 Incidents nach Release ausgewertet 
 Monitoring geprüft 
 Logs geprüft 
 Fachbereichsfeedback eingeholt 
 Knowledge Base aktualisiert 
 Runbooks aktualisiert 
 CMDB aktualisiert 
 Known Errors aktualisiert 
 Problem Record erstellt, falls erforderlich 
 Lessons Learned dokumentiert 
 
 
 Bedeutung für Fachinformatiker für Systemintegration 
 Fachinformatiker sind häufig direkt an Deployments beteiligt. 
 Im Alltag bedeutet das: 
 
 Versionen sauber dokumentieren, 
 Deployment-Schritte nachvollziehbar ausführen, 
 Abhängigkeiten prüfen, 
 Tests durchführen, 
 Monitoring beobachten, 
 Rollback vorbereiten, 
 Service Desk informieren, 
 Knowledge-Artikel aktualisieren, 
 und Fehler nach Releases strukturiert auswerten. 
 
 Gute technische Bereitstellung bedeutet nicht nur: 
 
 Installation erfolgreich. 
 
 Sondern: 
 
 Service funktioniert, Benutzer sind arbeitsfähig, Support ist vorbereitet und Dokumentation stimmt. 
 
 
 Zusammenfassung 
 
 Release-Inhalt festlegen 
↓ 
Changes, Risiken und Abhängigkeiten prüfen 
↓ 
Deployment vorbereiten 
↓ 
Service Desk und Benutzer informieren 
↓ 
technische Bereitstellung durchführen 
↓ 
Smoke Test und Monitoring prüfen 
↓ 
Release aus Benutzersicht bewerten 
↓ 
Incidents und Feedback beobachten 
↓ 
Knowledge, CMDB und Runbooks aktualisieren 
↓ 
Lessons Learned übernehmen 
 
 
 Merksätze 
 
 Release Management betrachtet die Bereitstellung aus Service- und Benutzersicht. 
 
 
 Deployment Management betrachtet die technische Überführung in eine Zielumgebung. 
 
 
 Ein erfolgreiches Deployment ist nicht automatisch ein erfolgreiches Release. 
 
 
 Service Desk und Benutzer müssen auf wichtige Releases vorbereitet sein. 
 
 
 Rollback und Kommunikation gehören vor dem Deployment geplant. 
 
 
 Nach einem Release müssen Knowledge, CMDB und Monitoring geprüft werden. 
 
 
 Verwandte Seiten 
 
 5.1 Change Enablement – Ziele, Begriffe und Abgrenzung 
 5.2 Change-Typen und Risikobewertung 
 5.3 Genehmigung, Planung und Umsetzung von Changes 
 5.5 Change-Erfolg messen und Continual Improvement 
 Incident Management 
 Problem Management 
 Knowledge Management 
 Service Configuration Management 
 
 
 Quellen und Versionsstand 
 Offizielle Grundlagen 
 
 PeopleCert – ITIL Practice Guide: Release Management 
 PeopleCert – ITIL Practice Guide: Deployment Management 
 PeopleCert – ITIL Practice Guide: Change Enablement 
 PeopleCert – ITIL Practice Guide: Incident Management 
 PeopleCert – ITIL Practice Guide: Problem Management 
 PeopleCert – ITIL Practice Guide: Knowledge Management 
 ITIL Foundation – Version 5 
 
 Einordnung 
 Die dargestellten: 
 
 Deployment-Methoden, 
 Checklisten, 
 Release-Plan-Inhalte, 
 Kommunikationshinweise, 
 Praxisbeispiele, 
 und Nachbereitungsfragen 
 
 sind herstellerneutrale Praxisempfehlungen. 
 ITIL schreibt keine universelle: 
 
 Deployment-Methode, 
 Release-Kalender-Struktur, 
 Release-Notes-Vorlage, 
 Testtiefe, 
 Rollout-Strategie, 
 oder Toolauswahl 
 
 für alle Organisationen vor. 
 Die konkrete Umsetzung muss an: 
 
 Services, 
 Risiken, 
 Benutzergruppen, 
 technische Architektur, 
 Change-Modell, 
 Deployment-Werkzeuge, 
 Sicherheitsanforderungen, 
 Lieferanten, 
 und organisatorische Fähigkeiten 
 
 angepasst werden. 
 Behandelter Framework-Stand: ITIL Version 5 
 Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance 
 Fachlicher Stand: August 2026