Sie brauchen einen Releasemanagement Berater und/oder möchten, dass wir Ihnen unser Angebot in diesem Umfeld vorstellen?
Bitte hinterlassen Sie uns Ihren Namen und die Kontaktdaten. Dann melden wir uns bei Ihnen.
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.
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.
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.
SAP Identity Management, Planung und Vorgehensweise beim Transport, in einem Howto erklärt.
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.
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.
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.
Haben Sie weitere Fragen zum Releasemanagement? Dann vereinbaren Sie eine kostenlose Websession mit uns. Ich freue mich auf den Kontakt.
Bitte hinterlassen Sie uns Ihren Namen und die Kontaktdaten. Dann melden wir uns bei Ihnen.