Release Management

Release Management einfach und verständlich erklärt

Der Begriff Release Management beschreibt die Planung, Umsetzung und das Controlling von Softwareentwicklungsprozessen und der angewendeten IT-Infrastruktur.

Release Management – Definition

Durch das Release Management wird es möglich, einen Überblick über den gesamten Entwicklungsprozess von Softwares, Web-Anwendungen und deren Updates sicherzustellen. Das Release Management kommuniziert mit dem Change- und dem Konfigurations-Management und stellt eine Schnittstelle zwischen der Risikoanalyse und den potenziellen Problemstellungen des Entwicklungszyklus (SDLC = Systems development life cycle) innerhalb einer IT-Infrastruktur dar.

Release Management – Aufgaben

Die Aufgabe eines Release Managements ist es, die Voraussetzungen an Änderungen von Updates, Rollouts, Patches und der verwendeten Infrastruktur im angesetzten zeitlichen Rahmen des Entwicklungsprozesses zusammen mit einem berechenbaren Risiko zu realisieren. Das Release Management

• Legt den Umfang der Funktionen einer Anwendung fest
• Gewährleistet Qualitätskontrollen
• Definiert die zeitlichen Rahmenbedingungen
• Dokumentiert alle Veränderungen
• Sorgt für ein reproduzierbaren Entwicklungsprozess

Das Release Management führt praktische, konzeptionelle und organisatorische Problemstellungen in einer Abteilung zusammen, um ein übersichtliches Monitoring für technische Änderungen von Rollouts und Releases innerhalb des Entwicklungsprozesses zu schaffen.

Release Management – Funktionen

Im Mittelpunkt steht der Begriff „Release“, welcher eine oder mehrere Änderungen enthält und durch „Versionsnummern“ wie beispielsweise „1.1“ gekennzeichnet wird. Unterstützt wird die Versionierung meist durch Versionskontrollsoftware wie

• Git
• Subversion (SVN)
• Mercurial
• Bazaar
• Monotone
• Perforce
• Fossil
• Darcs

Grundsätzlich wird zwischen folgenden Releases unterschieden:

1. Major Release: Der Major Release enthält neue oder überarbeitete Funktionen und Änderungen an der Architektur des Systems, welche Bugfixes überflüssig werden lassen und Minor- sowie Emergency Releases ersetzt werden.
2. Emergency Fix: Der Emergency Fix beinhaltet die Lösung von vereinzelten Konflikten.
3. Minor Release: Der Minor Release umfasst Änderungen und Erweiterungen, welche den Emergency Fix ergänzen können.

Sogenannte „Request for Changes“ werden vom Change-Management an das Release Management gesendet. Das finale Release bildet sich inhaltlich aus diesen Anforderungen. Begleitet wird das finale Release durch das Konfigurationsmanagement, in welchem die Prozesse in der IT-Infrastruktur strukturell gespeichert werden.

Dazu kommen noch die Versionsverwaltung sowie die Behandlung von Problemen zwischen der Infrastruktur und des Release. Hierbei nehmen die Integration und Dokumentation eine zentrale Rolle ein, um die Migration des Release in das Produktivsystem, welches den Release-Anwärter letztlich bereitstellt, zu vereinfachen.

Als finaler Schritt vor der Freigabe des Release gilt der Release Manager, welcher für den Kernprozess verantwortlich ist und die Aufgaben der Teams delegiert. Der Release Manager legt den zeitlichen Rahmen fest, definiert Ziele und setzt Fristen. Darüber hinaus kontrolliert er anhand von Checklisten den gesamten Ablauf und reagiert auf Feedback, welches nach dem Rollout des Releases eingeht.

Release Management mit ITIL

Das ITIL Framework, welches inzwischen in der Version V4 vorliegt, ist das meistgenutzte Konzept in Hinblick auf Enterprise-Lösungen. ITIL umfasst Regeln und Definitionen, welche den Betrieb einer IT-Infrastruktur in Bezug auf die organisatorischen Prozesse beschreiben. In ITIL 4 sind die Vorgänge von „Release und Deployment Management“ in zwei Praktiken enthalten: 1) Release Management 2) Deployment Management.

ITIL Release- und Deployment Management umfasst folgende Teilprozesse:

1. Release Planung: Ziel des Prozesses ist, die Zuordnung von Changes zu Release Packages und das Definieren des Volumens der Inhalte von Releases. Von diesen Informationen ausgehend entwickelt der Prozess der Release Planung einen zeitlichen Ablauf für die Erstellung, das Testen und das Ausrollen des Releases.
2. Release Build: Ziel des Prozesses ist es, die Erstellung der internen Aufträge und Anforderungen, welche notwendig sind, um die Release Komponenten entweder extern zu kaufen oder intern im Unternehmen zu entwickeln. Mit Abschluss dieses Prozesses sind die erforderlichen Komponenten für den Start der Release-Testphase einsatzbereit.
3. Release Deployment: Ziel des Prozesses ist, das Rollout der Komponenten in einer Live-Umgebung. Auch für die Weiterbildung von Endnutzern ist dieser Prozess zuständig – Zudem ist er dafür verantwortlich Informationen in Form von Dokumentationen zum ausgerollten Release zu verteilen.
4. Release Abschluss: Ziel des Prozesses ist es, nach einer Überprüfung von vollständigen Aktivitäts-Logs und ob alle CMS Inhalte aktuell gehalten sind, das Release abzuschließen.
5. Release Management Support: Ziel des Prozesses ist die Bereitstellung des Supports für das Rollout von Releases.
6. Early Life Support: Ziel des Prozesses ist, die Lösung von operativen Konflikten während der Anlauf-Phase nach dem Rollout und die Behebung ausstehender Fehler.

Je nach Modell (Beispielsweise Scrum oder „Agile Softwareentwicklung“) existieren verschiedene konzeptionelle Vorgehensweisen, welche sich nach den Phasen der Entwicklung einer Software ausrichten.

Release Management und Programmierung

Das Release Management wird meist als Unterstützung für die Qualität einer dienstleistungsorientierten IT-Anwendung dargestellt. Besonders auf Konzernniveau ist das Release Management ein fundamentaler Teil der IT-Abteilungen. Kritik erntet das Release Management von kleineren und mittelständischen Unternehmen – Diese führen oftmals an, dass es keine Alternative für kleinere Infrastrukturen gibt. Diese Unternehmen beziehen sich primär auf den Prozess-Ablauf nach dem ITIL Framework – Es sei zu komplex, um in kleinen Unternehmen Verwendung zu finden. Aufgrund dessen fordern eine Vielzahl von mittelständischen Unternehmen eine Light-Version, welche einen passenden Kern-Prozess mit sich bringt.

Die Lebensdauer einer IT-orientierten Lösung und die damit verbundenen Prozesse können bei kleinen oder mittelständischen Unternehmen allerdings durch andere Frameworks wie beispielsweise Integrated Service Management (ISM) ersetzt und auf die benötigten Bedürfnisse angepasst werden. Kleine und mittelständische Unternehmen haben durch Ihre meist minimale Infrastruktur ein besseres Maß an Flexibilität, um die Qualität des Service auch in Hinblick auf die Qualität und Effizienz zu verbessern. Hierbei kommt die Kombination aus Change-, Konfigurations- und Release Management zum Tragen, da dieser Teil auch von größeren Unternehmen oftmals als erfolgskritisch beschrieben wird.

Weblinks

• https://de.wikipedia.org/wiki/Releasemanagement
• https://www.ibm.com/docs/de/control-desk/7.6.1?topic=releases-release-management-overview
• https://www.panaya.com/de/blog/modernes-alm/release-management-prozess/
• https://www.microfocus.com/de-de/what-is/release-management
• https://wiki.de.it-processmaps.com/index.php/Release_Management
• https://t2informatik.de/wissen-kompakt/release/