Release Management Process

Freigabemanagement Prozess

Durch das BMC Release Process Management können Sie Änderungen an geschäftskritischen Anwendungen schneller, kostengünstiger und fehlerfreier umsetzen. ENTWICKLUNGS- UND RELEASE-MANAGEMENT-PROZESS / ENTWICKLUNGSPHASE. Freigabemanagement | IT-Prozess Wiki Prozessfähigkeit: Das Release-Management ist die Zentralbehörde, die dafür verantwortlich ist, Veränderungen an der IT-Infrastruktur so umzusetzen, dass sie wirkungsvoll, zuverlässig und verständlich ablaufen. Seine Aufgabe ist die Konzeption, Begleitung und Umsetzung von Ein- und Auslagerungen in Koordination mit dem Änderungsmanagement. Verfahrensziel: Umsetzung der Planungs- und Konzeptvorarbeiten im Rahmen eines Vorhabens.

Prozessfähigkeit: Schaffen der technologischen Vorraussetzungen für die Einführung oder Verbreitung der neuen Releasekomponenten und Stornieren des Produktivstarts im Fall von unvorhersehbaren Vorfällen. Verfahrensziel: Die Bestandteile des Release sowie die Verteilungs- und Rückfallprozeduren sollen einem realitätsnahen Testverfahren unterworfen werden, so dass eine begründete Entscheidungsfindung über den Beginn des Ausbaus möglich ist.

Prozessfähigkeit: Roll-out der Release-Komponenten in die Produktiv-IT-Umgebung und Kontrolle ihres Erfolgs. Freigabemanager: Als Zentralbehörde ist der Freigabemanager dafür verantwortlich, Veränderungen an der IT-Infrastruktur so umzusetzen, dass sie wirkungsvoll, zuverlässig und verständlich durchlaufen werden. Seine Aufgabe ist die Konzeption, Begleitung und Umsetzung von Ein- und Auslagerungen in Koordination mit dem Änderungsmanagement.

Kontinuierliches Implementierungs- und Release-Management - ein Gegensatz?

Of Continuous Integrated kommen wir über Continuous Delivery to Continuous Deployment. Von Continuous Integrated. Code-Änderungen und neue Funktionen werden nahezu unmittelbar und automatisiert in die Fertigung eingebracht. Release-Management und kontinuierlicher Einsatz scheinen sich auf den ersten Blick gegenseitig zu unterlaufen. Mit anderen Worten, was hat Release Management mit Continuous Deployment auszusetzen? Sind Release-Management für Führungskräfte und Continuous Deployment für Monteure?

Wird das Release-Management mit Continuous Deployment unnötig? Der Hauptzweck der Implementierung von Continuous Integrations (CI) ist es, dem Entwickler ein schnelles Rückmeldungen über seine Veränderungen zu geben. Das CI ist die Grundlage für eine kontinuierliche Lieferung, bei der jede Veränderung zu einer lieferbaren Lösung wird. Wenn jeder Bauabschnitt automatisiert bis zur Serienreife geliefert wird, spricht man von Continuous Deployment. In diesem Fall spricht man von Continuous Deployment. In diesem Fall handelt es sich um ein Continuous Depyment.

Das ist Release-Management? Beginnen wir mit einer Begriffsbestimmung für das Release-Management. Die Versionierung ist der Prozess der Verwaltung, Planung, Terminierung und Kontrolle der Erstellung von Logik durch verschiedene Phasen und Umgebungen, einschließlich des Testens und der Bereitstellung von Softwareversionen. Das Release-Management umfasst im herkömmlichen Sinne alles, was für den gesamten Produktlebenszyklus eines Release erforderlich ist.

Das beginnt bei der Festlegung und Projektierung, geht über die Weiterentwicklung und Qualitätskontrolle bis hin zur Instandhaltung nach dem Einsatz. Bereitstellung und Veröffentlichung erfolgen in etwa gleich oft, und das ist kein Zufall. Der Einsatz und die Veröffentlichung sind nicht zufällig. Weil "Freigabe" Freisetzung ist. Das heißt Freisetzung, Freistellung in der Fertigung. Wenn der Fokus sowieso nicht auf der Produktivsetzung liegt, durchlaufen die Veröffentlichungen (einschließlich Bugfixes) in der Klassikwelt ein teilweise komplexes Freigabeverfahren, das auch das Sammeln von Signaturen von autorisierten Genehmigenden umfasst.

Damit sind wir beim Thema Release-Management angelangt: Der Schritt zur Erzeugung eines Releases sollte im weiteren Sinn so gestaltet werden, dass ein Release geplant und gesteuert werden kann und in der Ziellandschaft ein eindeutig festgelegter Status verfügbar ist. Das ITIL Release & Deployment Management ist für die Planung, Definition und Kontrolle der Test- und Rollout-Phase eines Releases in der Live-Umgebung zuständig.

Hauptziel des Release Management und Bereitstellungsmanagements ist es, den Schutz der Live-Umgebung zu gewährleisten und dafür zu sorgen, dass nur bereits getestete Bauteile ausrollen. Die Erstellung eines Releases ist mit einem bestimmten Zeit- und Arbeitsaufwand behaftet. So wird die Häufigkeit für neue Funktionen verlängert. Wurden früher vierteljährlich neue Funktionen oder Funktionen veröffentlicht, so dauert der Sprint heute nur noch ein bis zwei Monate.

Agile Projekte erfordern daher eine andere Release-Planung, was weniger zeitaufwändig ist. Planen von Versionen von Scrum: Ein Plan auf sehr hohem Niveau für mehrere Sprints (z. B. drei bis zwölf Iterationen) wird bei der Release-Planung erstellt. Es wird eine Richtlinie erstellt, die die Erwartungen an die Merkmale, die umgesetzt werden sollen, und an den Zeitpunkt ihrer Umsetzung widerspiegelt.

Die Ablehnung kann eine Zwischenlieferung während des Projekts oder eine Endlieferung am Ende des Projekts sein. Wenn beispielsweise in Ecrum jeder Sprint ausführbare Programme liefert, kennzeichnen die Freigaben nun eine nachvollziehbare (!) Zusammenfassung von Vorteilen. Die Zwischenstufe Kontinuierliche Integrierung, bei der über kurze Build- und Testläufe dem Entwickler ein rasches Rückmeldungen gegeben werden, führt uns zu einer kontinuierlichen Bereitstellung über Continuous Delivery.

Mit der schnelleren Bereitstellung wird nicht nur die Ausfallzeit der tatsächlich erstellten Funktionen verkürzt, sondern auch der tatsächliche geschäftliche Nutzen der Funktionen. Kontinuierliche Lieferung und kontinuierliche Bereitstellung ermöglichen auch einen effektiveren Lernzyklus für Build-Measure-Learn, da der Nutzen individueller Veränderungen viel rascher und genauer geprüft und ausgewertet werden kann. Wenn Sie von kontinuierlicher Bereitstellung sprechen, können die Bezeichnungen "Release" und "Deployment" im Extrem unscharf werden, da das System bis zu mehrmals am Tag in die Produktivumgebung bereitgestellt wird (z.B. How-we-release-so-frequently).

Wenn Sie eine Bereitstellung von einem Release unterscheiden, ist es z.B. sinnvoll, eine Bereitstellung als einen regelmäßigen technologischen Prozess (Non-Event) zu sehen; eine Freigabe dagegen ist ein Logikkonstrukt, d. h. eine Zusammenstellung von Merkmalen, und sollte daher eingeplant werden. Das Release kann eine Änderung der Versionsnummer und eine Festlegung der darin enthaltene Funktionalität beinhalten.

Damit trotz der vielen Code-Änderungen lückenhafte Funktionen bereitgestellt werden können oder um unterschiedliche Funktionen parallel testen zu können, sind Funktionsumschaltungen eine gute Idee - aber das ist ein anderes Fach. Inwiefern verändert sich das Release-Management beim Wechsel zu Flexibilität und kontinuierlicher Bereitstellung? Im Falle klassischer Release-Zyklen mit relativ seltenem Release können in den einzelnen Etappen folgende Tätigkeiten auftreten (die Abbildung ist natürlich nur ein einfaches Beispiel; vor allem ein detaillierter Rollout-Plan bedarf einer intensiveren Betrachtung):

In der Tat besteht ein großer Teil der Arbeiten darin, die Differenzen zwischen der vorherigen und der neuen Fassung zu identifizieren, die Umstellung zu vorbereiten, den Produktivstart durchzufÃ? Abhängig von Firma, Projekt und Leistung kann die Vorbereitung und Umsetzung des Release-Wechsels allein schon zu wochenlanger Vollarbeit und Seiten von Planungsunterlagen führen.

Beim Release-Wechsel (oft auch Rollout-Wochenende genannt) sind alle Teilnehmer in der Lage, ihre Rollout-Schritte nach Ankündigung auszuführen. Für die Stabilisierung des neuen Releases sind die folgenden Tage oder Woche geplant, oft mit enormer Überstundenzahl (The Manager's Guide to Continuous Delivery, Andrew Philips et al, 2014 Xebia B.V.).

Bei der Umstellung auf agile Verfahren und Continuous Deployment werden die Steigerungen kleiner, so dass dieser Arbeitsaufwand nicht mehr für jedes Release durchgeführt werden kann und sollte. Das Management oder der Produkteigentümer entwirft und prüft die zu erstellenden Funktionen, die Entwicklerteams und der Betrieb stellen die Umsetzung, den Einsatz und die Funktionalität sicher. Neben der Festlegung der zu entwicklenden Merkmale in der Sprint-Planung und der Festlegung der zu messenden unternehmensrelevanten Erfolgkriterien und deren anschließender Überprüfung durch den Produktverantwortlichen (Scrum) sind alle weiteren Arbeitsschritte in der Verantwortlichkeit der Entwickler: Die Entwickung eines Merkmals und die Definition von getan beinhaltet nicht nur den getesteten Quellcode, sondern auch die Mittel zur automatischen Verteilung des Merkmals.

Die Einführung agiler Verfahren mit kurzen Release-Zyklen ist nicht nur von Vorteil, um die Softwarequalität zu steigern, indem man den Entwicklern schnellere Rückmeldungen gibt. Immer häufiger auftretende Freigaben führen unweigerlich zu einer Erhöhung der Automatisierung und damit der Produktqualität und reduzieren den damit verbundenen Arbeitsaufwand und das damit verbundene Ausfallsrisiko. Das macht das Release-Management nicht überflüssig, sondern fokussiert auf wertschöpfende Aufgaben:

Planung der erforderlichen Funktionen und deren Auswertung im Rahmen des Zyklus Build-Measure-Learn. Darüber hinaus zeigt sich, dass der kontinuierliche Einsatz nicht nur auf der technischen Seite erfolgt, sondern sich auf den gesamten Software-Lebenszyklus und die gesamte Firmenkultur auswirkt, indem die unterschiedlichen Funktionen ineinandergreifen.

Mehr zum Thema