In einer Release Planung werden die zum kommenden Release Terminen erwarteten Änderungen der betroffenen Systeme bzw. Applikation dargestellt.
Transparenz über Status von Applikationen in Test- und Produktionsumgebung |
Langfristige zeitliche Planbarkeit der Weiterentwicklung von Software |
» Gemeinsame Realisierungszeiträume |
» Gemeinsame Test-Zeiträume |
» Gemeinsame Termine zur Datenübernahme in die Testumgebung |
» Systemübergreifend getestete und stabile Software in Produktion |
Risikominimierung für die Produktionsumgebung |
» Durch Reduzierung von Datenübernahmen außerhalb des Release |
» Durch Bündelung von Einzelmaßnahmen und Überführung in das Release |
» Durch Schaffung von Zeitfenstern für betriebliche Wartungsmaßnahmen |
Planbarkeit des Testaufwands im Fachbereichen und der IT |
» Durch rechtzeitige Planung von Testzeiträumen |
» Durch termingerechte Koordination gemeinsamer Testumgebungen |
» Durch Abstimmung applikationsübergreifender Termine zur Datenübernahme in Testumgebung |
Ressourcenplanung durch Bereitstellung geplanter Release Fenster / Testzeiträume |
Klare Kommunikationswege, definierte Rollen, Reduzierung Abstimmungsaufwand. |
Folgende wesentliche Anforderungen hat ein Release Management Prozess zu erfüllen:
Transparenz |
» Sammlung aller geplanten Änderungen pro Systemlinie |
» Zentrale Dokumentation aller Änderungen zu einem Release Fenster |
Information und Kommunikation |
» Aktive Information der Cut Over Planungen (Detailplanung der Produktivsetzung) |
» Kommunikation bei Planabweichungen/ Eskalation |
Geregelter Ablauf |
» Regelung der Rollen und Ansprechpartner |
» Strukturierung der operativen Release Prozesse |
» Regelung von Kompetenzen |
Release planen |
» Durchführung der planerischen und konzeptionellen Vorarbeiten |
» Abfrage der Cut Over Planung |
» Zusammenführung von mehreren Cut Over Planungen |
» Zentrale Ablage der Cut Over Planungen |
» Release Kick Off bei Abstimmungsbedarf hinsichtlich Abhängigkeiten und Risiken |
Release durchführen |
» Kommunikation des Status an alle Beteiligte über zentralen Kanal |
» Steuerung von Problemlösungen durch Koordination der Beteiligten |
» Steuerung Eskalation durch Benennung Eskalationsmanager/ Definition Eskalationsprozess |
Release nachbetrachten |
» Review mit allen Beteiligten durchführen |
» Dokumentation von offenen Punkten und notwendige Nacharbeiten |
» Monitoring der Nacharbeiten |
Die Kernkompetenz eines Release Management |
» Genehmigung/ Ablehnung von Sonder Release |
» Einholung Entscheidung im Release Board * (sofern nicht auflösbare Abhängigkeiten bestehen) |
» Anstoßen von Eskalationsprozessen |
|
* Eine Release Board ist zuständig für die gesamte Release Planung im Unternehmen |
Ein zentrale Release Management ist zuständig für: |
» Festlegung und Weiterentwicklung von Standards/ Grundsätzen und Verfahren |
» Dokumentation der Rahmenbedingungen zum Release Management |
» Etablierung der Standards und Verfahren |
» Erstellung und Pflege einer jahresübergreifenden Planung von Release -Terminen |
» Gewährleistung der Nachhaltigkeit durch ein regelmäßiges Monitoring der Release Planung |
» Beratung und Unterstützung des operatives Release Management und deren Projekte |
» Einbeziehung des Testumgebungsmanagements in die Planungsabstimmungen |
Ein operative Release Management ist zuständig für: |
» Festlegung von Entwicklungen, die in einem Release produktiv gesetzt werden sollen |
» Fachliche, technische oder organisatorische Abstimmung mit Projektleitern |
» Terminabstimmung der Release Fenster und der Datenübernahmen in die Testsysteme |
» Sicherstellung von Testdurchführung und Testfreigaben, bezogen auf das jeweilige Release |
» Erarbeitung einer Einführungsplanung und Kommunikation an die beteiligten Personen |
» Regelmäßige Prüfung und Mitteilung von notwendigen Release Änderungen |
» Umsetzung vom definierten und veröffentlichten Standards, Verfahren und Grundsätze |
Release Arten |
||
Major Release |
» Größerer Entwicklungsumfang, längerer Testzeitraum |
|
Minor Release |
» Kleinerer Entwicklungsumfang, kürzerer Testzeitraum |
|
Sonder Release |
» Änderungen werden als Ausnahmefall produktiv gesetzt |
|
|
Restriktionen: Verfügbarkeit der Testumgebung und konsistenter Testdaten muss gewährleistet sein |
|
Emergency Release |
» Änderungen aufgrund von hoch priorisierten Incidents (Bug Fix, Hot Fix) |
|
Patch Day |
» Korrekturauslieferung für eine Software (z.B. Sicherheitspakete, Kernelpatches, Service Packages) ohne Notwendigkeit von Integrationstests über mehrere Testsysteme |
Ziele und Zuständigkeiten eines Testumgebungsmanagements |
» Sicherstellung der technischen Verfügbarkeit einer konsistenten Testumgebung |
» Schaffung einer Transparenz über laufende Testaktivitäten |
» Koordination von Störungen innerhalb vereinbarter Testzeiträume |
» Unterstützung der Testkoordination bei deren Aufgaben |
» Begleitung des Aufbaus der Testumgebung |
» Klärung der Anforderungen an die Testumgebung und an die Testdaten |
» Koordination von Testdatenaktualisierungen (= Systemkopie der Produktionsumgebung) |
» Klärung von Fehlern und Störungen in der Testumgebung während der Testzeiträume |
» Information über geplante und ungeplante Ausfälle der Testumgebung für die Testzeiträume |
Projektnummer |
|
|||||
Projektbezeichnung |
|
|||||
Projekt Kurzbeschreibung |
|
|||||
|
|
|||||
Applikation * |
System/ Systemlinie |
Go- Live Termin |
Kommentar |
|||
Nummer |
Name |
Zentrales Release |
Sonder- |
Antrag Sonder- |
||
… |
|
|
|
|
|
|
… |
|
|
|
|
|
|
|
||||||
* Hier sind alle Applikationen aufzulisten, die im Rahmen dieses Projektes eine Veränderung erfahren und zu dem angegebenen Go Live-Termin in den Betrieb überführt werden. |