Projekte - Release

In einem Releaseverbund werden verschiedene Auslieferungseinheiten zusammengefasst, die für spezifische fachliche Anforderungen eines Bereichs notwendig sind. Ein Releaseverbund bezeichnet somit die Zusammenstellung aller relevanten Releases der beteiligten Auslieferungseinheiten, die für eine fachliche Funktionalität oder einen Geschäftsprozess benötigt werden. Jedes Release innerhalb dieses Verbundes repräsentiert einen definierten und festgelegten Zustand einer Auslieferungseinheit.

Ein Release ist eine Menge fachlich, technisch oder organisatorisch zusammengehörender, autorisierter Änderungen, die zu einem gemeinsamen Zeitpunkt auszuliefern sind und kann für eine einzelne Applikation aber auch für eine Menge von Applikationen innerhalb einer Systemlinie oder systemlinienübergreifend zusammengestellt werden.

Jedes Release durchläuft mit seinem definierten Umfang den Release Management-Prozess.

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

Zu jedem Release wird im Rahmen eines Release Planungsprozesses ein Testzeitraum festgelegt, welcher mit einer festgelegten Zeitspanne (Tage oder Wochen) vor dem Release Termin beginnt.

Nach Beginn des Testzeitraums sollten - im Sinne eines stabilen Tests - abgestimmt nur noch Entwicklungen zur Fehlerkorrektur (Bug Fixing) in die Testumgebungen eingespielt werden. Ein Testzeitraum hat technische Integrationstests, Funktions- und Funktionskettentests sowie einen User Acceptance Test zu berücksichtigen.

Der Umfang der im Testzeitraum zu testenden Entwicklungen sollte im angemessenen Verhältnis zum vorhandenen Testzeitraum stehen, damit alle geplanten Tests durchgeführt werden können und in der Folge eine möglichst fehlerfreie Entwicklungen erreicht werden kann.

Zu Beginn des Testzeitraums müssen auch alle Testumgebungen und alle relevanten Entwicklungen auf der Testumgebung zur Verfügung stehen. In größeren und komplexeren Projekten kann ein Testumgebungsmanager eingesetzt werden

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

Zustände eines Releases

Ein Release durchläuft im Rahmen seines Lebenszyklus verschiedene Zustände:

Eingefroren
Ein Release im Zustand "eingefroren" ist finalisiert und wird zur Auslieferung vorbereitet. In diesem Zustand dürfen weder die Bezeichnung noch der Inhalt des Releases geändert werden.
Freigegeben
Nach erfolgter Freigabe wechselt das Release in den Zustand "freigegeben" und ist für den Einsatz in der Produktionsumgebung bereit.
Inaktiv
Ein Release wird als "inaktiv" betrachtet, wenn es in der Produktionsumgebung durch ein nachfolgendes Release ersetzt wurde oder wenn es vor der Freigabe durch ein nachfolgendes Release im Freigabetest ersetzt wurde. Für inaktive Releases werden keine Fehlerbehebungen mehr durchgeführt.

Verwaltung der Releasezustände

Die Zustände eines Releases sind in der Regel außerhalb des Konfigurationsmanagementsystems (KMS) zu verwalten, da die Zustände nicht direkt aus dem KMS ersichtlich sind. Ein Zustandswechsel eines Releases erfordert unter Umständen eine Kennzeichnung (Labeling) im KMS, wie z.B. der Wechsel von „eingefroren“ zu „freigegeben“.

Fehlerbehebung und Releasepflege

Sowohl für eingefrorene als auch für freigegebene Releases können Fehlerbehebungen erforderlich sein. Um den Pflegeaufwand zu minimieren, wird eine möglichst geringe Anzahl gleichzeitig eingefrorener oder freigegebener Releases angestrebt. Dies dient der Komplexitätsreduktion im Releasemanagement und der Effizienzsteigerung bei der Fehlerbehebung.

Zielsetzungen im Releasemanagement

Zur Verringerung der Komplexität und zur Sicherstellung eines effizienten Releasemanagementprozesses wird empfohlen, freigegebene Releases zeitnah in die Produktionsumgebung zu überführen. Dies ermöglicht eine klare Strukturierung und erleichtert die Verwaltung der unterschiedlichen Releasezustände.