Ein Release beschreibt die Veröffentlichung bzw. die Freigabe einer neuen Entwicklung/Software oder einer neuen Version einer bereits bestehenden Entwicklung. Das Releasemanagement beschreibt demnach die Planung und die Durchführung der Veröffentlichung.
Wozu benötigt ein Unternehmen das Releasemanagement? Die Entwicklungsbereiche wissen doch eigentlich am besten, welche Aufträge sie wann und wie zu transportieren haben. Aber so ganz stimmt das nicht. In einem Unternehmen gibt es schließlich nicht nur einen Entwicklungsbereich, sondern mehrere. Diese müssen sich demnach bei den Deployments untereinander abstimmen: Bestehen mögliche Abhängigkeiten? Wann darf welcher Bereich transportieren, ohne dabei das Tagesgeschäft zu vernachlässigen oder andere Einspielungen zu stören? An dieser Stelle kommt das Releasemanagement (RM) ins Spiel: Das RM plant, überwacht und führt auch in einigen Fällen selbst die Transportprozesse durch.
Ziel des Releasemanagements ist es, Updates oder auch neue Anforderungen in einem zeitlichen Rahmen zu realisieren und dabei das (Geschäfts-)Risiko möglichst gering zu halten. Im ITIL-Kontext ist das RM dabei ein Teil der Service Transition, also der Überführung eines Services/mehrerer Services in die produktive Umgebung.
Das können Sie mitnehmen:
- Einen Einstieg in das Release Management im SAP
- Eine Übersicht der Best Practices zum Release– und Transportmanagement
- Eine Einführung in das Thema Release– und Transportmanagement mit SAP ChaRM im Solution Manager anhand praktischer Anwendungsszenarien
- Einen Überblick darüber, welche Schnittstellen es zum Release Management (Technisch/ Prozessual) gibt und welche Möglichkeiten der Solution Manager zur Unterstützung bietet (Schnittstelle IT-Service Management, Schnittstelle Testmanagement, Business Process Change Analyser)
Zentrales Releasemanagement vs. Operatives Releasemanagement
Der Hauptunterschied zwischen dem zentralen und dem operativen Releasemanagement besteht darin, dass das Zentrales Releasemanagement (ZRM) eher auf strategischer Ebene unterwegs ist. Im zentralen Releasemanagement werden die Prozesse (wie z. B. die Release Policy – die sog. Release-Richtlinien) vorgegeben, neue Entscheidungen beschlossen und der Überblick über das ganze Releasemanagement behalten – immer in enger Zusammenarbeit mit dem Operatives Releasemanagement (ORM). Wohingegen das ORM die vorgegebenen Prozesse lebt und darauf achtet, dass diese auch von den jeweiligen Fachbereichen eingehalten werden. ZRM und ORM stehen dabei im ständigen Austausch.
Release-Arten
Zu einem Release angemeldete Entwicklungsaufträge können dabei auf unterschiedlichem Weg produktiv gesetzt werden – dieser Vorgang ist von eventuellen Abhängigkeiten zu anderen Applikationen, vom Produktivsetzungsrisiko oder auch von der Priorität abhängig.
- Major Release: Enthält Anforderungen, die auch durch ein Minor Release oder Emergency Fix deployed werden können. Bei einem Major Release ist der Vorteil, dass die Fachbereiche mehr Zeit für die Planung, Entwicklung und Tests zur Verfügung haben.
- Minor Release: Alle Anforderungen mit geringer Priorität können über einen Minor Release produktiv gesetzt werden. Diese Option hat den Vorteil, dass kurzfristig Änderungen in die Produktivumgebung transportiert werden können.
- Emergency Fix: Diese Variante beinhaltet Änderungen, die eine hohe Priorität haben und dementsprechend sofort produktiv gesetzt werden müssen und somit nicht bis zu einem nächsten Release-Termin warten können. Voraussetzung für einen solchen Emergency Fix ist ein Major Incident, also eine Störung mit hoher Priorität, und ein entsprechender Emergency Change, der durch einen sog. Emergency CAB (Change Advisory Board) autorisiert werden muss.
Relevanz von Changes
Produktiv gesetzt werden die Entwicklungsaufträge immer in Form von Changes. Diese umfassen das Überführen von Änderungen an einer Applikation/einem System. Dort wird mittels der Configuration Items (CIs) angegeben, an welchen Teilen einer Applikation die genauen Änderungen stattfinden. Außerdem wird dort ganz genau geschildert, wann das Deployment stattfindet, wie dabei vorgegangen wird oder was im Falle einer Störung zu tun ist. Changes dienen also zur Unterstützung und Kontrolle bei der Überführung in die Live-Umgebung.
Abgrenzung zum Changemanagement
Release- und Changemanagement arbeiten fest verankert zusammen. Doch wo genau liegt der Unterschied? Das Changemanagement beschäftigt sich vor allem mit Genehmigungen von Changes – es kann also als Qualitätskontrollprozess bezeichnet werden. Wohingegen das Releasemanagement sich mit dem eigentlich Doing beschäftigt, also um die Durchführung genehmigter Changes und darauf achtet, dass die Einspielungen korrekt stattfinden.
Fragen zum Releasemanagement
Haben sie Fragen zum Thema Releasemanagement oder sehen Sie Entwicklungspotential in Ihrem Unternehmen? Wir beraten Sie gerne und beantworten Ihre Fragen. Verbinden Sie gerne ein Beratungsgespräch mit unseren Experten der mindsquare Managed Services.
Websession: Releasemanagement
Haben Sie weitere Fragen zum Releasemanagement? Dann vereinbaren Sie eine kostenlose Websession mit uns. Ich freue mich auf den Kontakt.
