Information Technology Reference
In-Depth Information
dem Change Management und Veränderungsprojekten werden verständliche Release- und
Deployment-Pläne erstellt und verfügbar gemacht.
Entsprechend den unterschiedlichen Anforderungen aus verschiedenen Releases und deren
Inhalten legt man das passende Release Design fest und implementiert die Releases entspre-
chend. Klassische Alternativen für das Release Design sind Push- oder Pull-Mechanismen,
automatische oder manuelle Methoden, „Big Bang“ oder stufenweise Implementierung.
4.2.8.2■Begrife
Release unit
Die Release Unit ist der Teil eines Service bzw. der IT-Infrastruktur, der in der Regel während
eines Releases gemeinsam getestet und ausgerollt wird. Ziel ist es, den geeigneten Release
Unit Level für die vorhandenen Service Assets je nach deren Einluss auf die Geschätspro-
zesse zu deinieren. Beispielsweise kann bei geschätskritischen Applikationen deiniert
werden, dass die Release Unit grundsätzlich die gesamte Applikation umfasst, um in Tests
alle möglichen Auswirkungen zu identiizieren.
Release Package
Ein Release Package beinhaltet die notwendigen Veränderungen, um Services von einer
vorhandenen Baseline auf eine neue, geplante Baseline zu verändern. Geplante Changes
bedingen ot weitere Veränderungen (wie z. B. ein Hardware-Upgrade aufgrund einer Sot-
wareaktualisierung), die im Rahmen des Release Package gemeinsam betrachtet werden.
Auch neue Handbücher, Systemdokumentationen oder Vorgehensweisen können Inhalt
eines Release Package sein.
Release Packages können aus einer oder mehreren Release Units bestehen. Sie sollten so
gestaltet werden, dass die Möglichkeit besteht, einzelne Release Units bei Bedarf (z. B. auf-
grund entsprechender Testergebnisse) aus dem Package zu entfernen.
Release- und Deployment-Modelle
Release- und Deployment-Modelle sind vordeinierte Modelle, die bei der Verteilung von
Releases unterstützen und einen Rahmen für Rollouts schafen. Diese Modelle enthalten
Informationen zur Release-Struktur (Gestaltung des Release Package und Informationen zur
Zielumgebung), Kriterien für Start und Ende eines Releases. Für die Durchführung werden
die Entwicklungs- und Testumgebungen, Rollen, Zeitpläne, Templates und Vorgaben für die
Dokumentation sowie Übergabe- und Abnahmekriterien beschrieben. Die bereits genannten
Release-Optionen sind:
Big Bang:
Alle Komponenten eines Releases werden gleichzeitig in die Betriebsumgebung
eingeführt. Dieser Ansatz verkürzt die Dauer und fasst die Einschränkungen des Betriebes
durch den Rollout zusammen, birgt jedoch ein höheres Risiko für erhebliche Beeinträch-
tigungen des Betriebs.
Phased:
In dieser Variante indet der Rollout phasenweise, z. B. nach Standort oder Funktio-
nalität, statt. Hier besteht ein vermindertes Risiko für weitreichende Beeinträchtigungen;
Erfahrungen aus den ersten Phasen lassen sich für die danach folgenden verwenden.
Allerdings besteht die Gefahr einer erheblichen zeitlichen Ausdehnung der Behinderungen
durch die Rollouts.
