Was ist ein Release in der Softwareentwicklung?
In der Softwareentwicklung ist ein Release eine neue oder modifizierte Software und der Prozess ihrer Erstellung. Ein Release stellt eine voll funktionsfähige Version einer Software dar und ist der Höhepunkt der Softwareentwicklungsprozesse. In der Regel gehen dem Release Alpha- und Beta-Versionen der Software voraus.
Alpha- und Beta-Versionen können zwar auch Alpha- oder Beta-Releases genannt werden, aber im Singular bezieht sich Release in der Regel auf die endgültige Version der Software. Manchmal werden Releases auch als Launches oder Inkremente bezeichnet.
Die meisten Organisationen identifizieren Releases mit einer eindeutigen Zahlen- oder Buchstabenabfolge, die sequenziell aktualisiert werden. Dieser Benennungsprozess wird als Softwareversionierung bezeichnet. Es gibt keine allgemein für Branchen geltenden Regeln dafür, wie sich diese eindeutigen Identifikatoren von Release zu Release zu ändern haben, aber jedes Unternehmen folgt konsequent seinem eigenen internen Standard.
Was ist der Releasemanagementprozess?
Durch den Fokus auf das Releasemanagement verbessern Organisationen die Qualität, Geschwindigkeit und Effizienz der Erstellung und Aktualisierung von Software. Dies ist der Prozess der Planung und Verwaltung eines Software-Builds in den Phasen der Entwicklung, Testung, Bereitstellung und Supports des Releases. Techniken wie Agile-Entwicklung, Continous Delivery, DevOps und Releaseautomatisierung haben dazu beigetragen, das Releasemanagement zu optimieren. Die Schnelligkeit dieses Prozesses hat sich in letzter Zeit derart gesteigert, dass Amazon vor einigen Jahren die Marke von 50 Millionen Code-Bereitstellungen pro Jahr überschritten hat – mehr als eine pro Sekunde.
Releasemanagement ist eine relativ neue Disziplin in der Softwareentwicklung, wächst jedoch dank rasanter Innovationen in der Technologie schnell. Als Disziplin stützt es sich sowohl auf das traditionelle, geschäftsorientierte Projektmanagement als auch auf das technische Wissen über den Lebenszyklus der Systementwicklung (systems development life cycle/SDLC) und der IT Infrastructure Library, einer Reihe von Praktiken für das IT-Servicemanagement.
Die Ziele und Vorteile des Releasemanagements
Bei effektiver Anwendung erhöht das Releasemanagement die Anzahl erfolgreicher Releases einer Organisation und reduziert Qualitätsprobleme. Produktivität, Kommunikation und Koordination werden verbessert, und die Organisation kann Software schneller liefern und gleichzeitig das Risiko verringern.
Diese Verbesserungen bedeuten, dass das Team wiederholt qualitativ hochwertige Software bei kürzeren Markteinführungszeiten produzieren kann, was es dem Unternehmen ermöglicht, besser auf die Betriebsumgebung zu reagieren.
Das Releasemanagement hilft auch, den Entwicklungs- und Betriebsprozess zu standardisieren und zu optimieren. Das Team implementiert überprüfbare Releasekontrollen und erstellt so ein Repository für alle Releases im gesamten Lebenszyklus. Ein einziger, gut dokumentierter Prozess, der für alle Releases befolgt werden muss, erhöht die organisatorische Reife. Eine verstärkte Standardisierung und der Fokus auf das Produkt ermöglichen es Teams, nützlichere Erkenntnisse aus Ihren Erfahrungen zu erlangen und sie für zukünftige Releases anzuwenden.
Betriebsabteilungen schätzen die verstärkte Koordination mit den Entwicklern, da es weniger Überraschungen gibt. Sie können jetzt das Gefühl loswerden, dass sich die Entwicklungsabteilung zu wenig Zeit für ein Release genommen hat und sie deshalb aufgrund enger Fristen Notlösungen finden müssen. Es gibt auch mehr Möglichkeiten, Konfigurationsprobleme zwischen den Entwicklungs- und Betriebsumgebungen zu lösen.
Kurz gesagt überwindet das Releasemanagement Hindernisse zwischen Teams mit unterschiedlichen Funktionen in einer IT-Organisation. Infolgedessen können Sie die Produktbereitstellung ganzheitlich verbessern.
Gabriel Gutierrez, a Solutions Architect at Boeing and former Release Manager at Costco, says that when executing a release, it’s important to give adequate consideration to the impacts on other areas of the organization. “Companies must provide a common forum where changes are fully vetted and put through thorough architectural and design reviews that eventually lead to integrated testing. Cross-functional and technical reviews are essential to minimizing the inevitable pain after go-live. A smooth post-go-live operation is a critical success factor of any release,” he explains.
Eine kurze Geschichte des Releasemanagements
Der Aufstieg des Releasemanagements ist auf die Umstellung der Softwareentwicklung von projektbasierten zu produktbasierten Angeboten zurückzuführen. Unter dem projektbasierten Entwicklungsparadigma betrachteten Softwareentwickler jedes Release als Projekt und nicht als Produkt; voll entwickelte Software signalisierte meistens, dass kein Entwickler mehr gebraucht wurde.
Im Laufe der Zeit entwickelte der Softwareentwicklungsprozess jedoch mehr und mehr Ähnlichkeit zum Produktzyklus, in dem Produkte über eine lange Laufzeit hinweg unterstützt, verbessert und immer wieder neu veröffentlicht wurden. In diesem Rahmen war das Release nicht das Endziel der Entwicklung, sondern vielmehr ein Übergangspunkt für den Support und die Überarbeitung.
Mit dieser zunehmenden Komplexität wuchs die Notwendigkeit, die Phasen zu koordinieren. Aus diesem Grund sind aktuelle Praktiken im Releasemanagement zum Teil von den Prinzipien eines geschäftsorientierten Projektmanagements inspiriert, und umfassen auch den After-Sales-Support und die Weiterentwicklung.
Releasemanagement ist Teil der größeren IT-Disziplin des Change-Managements, das sich mit den grundsätzlichen Turbulenzen der Softwareentwicklung befasst, wo sich die Anforderungen der Stakeholder ständig ändern können und sich die Compliance- und Regulierungsvorgaben weiter verändern. Um in dieser Umgebung den Kurs zu halten, müssen Softwareentwicklungsprozesse gut synchronisiert sein. Das Releasemanagement hilft, dieses Ziel zu erreichen. (Hinweis: Change-Management sollte nicht mit organisatorischen Änderungen verwechselt werden, was die Umgestaltung der Kultur, die Mitarbeiterfluktuation und die interne Umstrukturierung von Organisationen ist.)
A “common pitfall is disregarding the importance of a well-thought-out change management process,” says Jen Dunbeck, a release manager at automated IT services provider BitTitan. “A change control board's or change advisory board's significance cannot be underestimated in a release. A key function of their job is to help the organization assess risk and impact with impartiality. They also help root out technical dependencies that may not have been evident as individual contributions to the deployment,” she adds.
Um Ihren Change-Managementprozess zu entwickeln, sind Standardabläufe zum Vorschlagen von Projektänderungen und Erfassen von genehmigten und implementierten Änderungen hilfreich. Machen Sie den ersten Schritt, indem Sie die folgenden kostenlosen Vorlagen für einen Änderungsvorschlag und ein Change-Managementprotokoll herunterladen.
Vorlage für Änderungsvorschlag
Ein Änderungsvorschlag beschreibt die Art und das Ausmaß der Änderung und ist oft der erste Schritt in einem Change-Managementprozess. Beschreiben Sie, warum die Änderung erforderlich ist, die erwarteten Ergebnisse und Auswirkungen, den Zeit- und Ressourcenaufwand und alle anderen Faktoren, die überprüft werden müssen. Diese Vorlage enthält auch Platz für das Hinzufügen beschreibender Informationen sowie Abschnitte für die Berechnung von Kosten und Nutzen.
Change-Managementprotokoll
Ein Change-Managementprotokoll ist ein Dokument, das nachverfolgt, wer wann welche Änderung angefordert hat, den Status der Änderungsanforderung, dessen Priorität und Informationen zum Entschluss. Wenn Sie eine gründlichere Aufzeichnung benötigen, fügen Sie andere Details wie die Art und die Auswirkungen der Änderung hinzu. Diese Protokollvorlage wurde entwickelt, um wichtige Informationen nachzuverfolgen, sodass Änderungsanforderungen problemlos priorisiert, behandelt und später referenziert werden können.
So funktioniert das Releasemanagement: Ein Überblick
Nicht jede Software ist gleich. Je nach Funktionsweise und Anwendung des Programms variiert der Softwareentwicklungsprozess in der Strenge und Intensität.
Zum Beispiel wird Software, die für den Einsatz in Flugzeugen entwickelt wird, strengen Tests unterzogen. Sie müssen eine umfassende Dokumentation erstellen und mehrere Fixes implementieren, wenn die Software nicht innerhalb der engen Leistungstoleranzen liegt. Funktionale Anforderungen und Qualitätsmetriken sind streng, und die Software muss viele Genehmigungsstufen durchlaufen, bevor sie in einem Flugzeug zum Einsatz kommt.
Ein disziplinierter Releasemanagementprozess trägt dazu bei, dass Software in Einklang mit den Bestimmungen der wichtigsten Stakeholder entwickelt, getestet und geliefert wird. Das Team überprüft die Software, um zu sehen, ob sie das tut, was sie tun soll, und ob sie im Zeitplan liegt.
Das Releasemanagement kombiniert die folgenden Elemente in einem zentralen Repository:
- Die geschäftliche Notwendigkeit, Kunden das zu geben, was sie brauchen, wenn sie es brauchen
- Die technischen Aufgaben der Qualitätssicherung und Compliance
- Die Verwaltung von Software-Artefakten
Die Artefakte werden zur Anwendungsbereitstellung aus dem Repository für eine Client-Produktionsumgebung freigegeben. Sie können sich das Releasemanagement also als das Bindemittel vorstellen, das die miteinander verbundenen, aber unterschiedlichen Aufgaben zusammenhält, welche die Softwareentwicklung umfassen: Design, Entwicklung, Tests, Bereitstellung, Wartung sowie Geschäfts- und Kundenanforderungen.
Ein Release umfasst mehr als nur die Kernfunktionen der Softwareentwicklung. Während Entwickler ein Release offensichtlich als erfolgreiche Lieferung eines fertigen Produkts betrachten, gibt es zahlreiche unterstützende Geschäftsaktivitäten, die ebenfalls eine Rolle spielen, wie die Schulung von Vertriebs- und Kundendienstmitarbeitern sowie die Werbung und das Marketing für das neue Release. Diese Aktivitäten müssen auf das Release-Tempo abgestimmt sein, was den Releasemanagementprozess noch komplexer macht.
Darüber hinaus ist Releasemanagement nicht nur für neu entwickelte Software gedacht. Modifizierte Software durchläuft den gleichen Prozess, um sicherzustellen, dass die Stakeholder das bekommen, was sie wollen.
Die tatsächliche Veröffentlichung kann manuell erfolgen oder, in zunehmendem Maße, automatisiert werden, je nachdem, wie ausgereift der Releasemanagementprozess ist. (Amazon verwendet einen automatisierten Veröffentlichungsprozess, um jede Sekunde ein neues Release zu veröffentlichen. In der Vergangenheit waren wöchentliche, monatliche und vierteljährliche Aktualisierungen typischer für Softwareentwicklungsteams.)
Releases gibt es in vielen verschiedenen Formen: als physisches Produkt in einer Verpackung, als Download von einer Website oder einem Server, als Push auf ein Gerät von einem mobilen App-Store oder als nahtlose Aktualisierung einer webbasierten Anwendung.
Jede Softwareentwicklungsgruppe – ob groß oder klein und in allen Branchen – wenden Releasemanagement an, um den Prozess zu vereinfachen. Sie können es auf interne oder als Produkt verkaufte Software anwenden. Große und kleine Softwareentwicklungsgruppen nutzen unabhängig von der Branche Releasemanagement und nutzen die daraus resultierende Software, um ihre eigenen Produkte oder Systeme zu betreiben oder sie als eigenes Produkt an Kunden zu verkaufen.
Einer der Entwicklungsansätze, die dem Releasemanagement am besten zuträglich sind, ist DevOps, ein Begriff, der durch die Kombination der Wörter development (Entwicklung) und operations (Betrieb) gebildet wird. Wie der Name schon sagt, versucht DevOps, die Koordination zwischen Entwicklern und dem Betrieb in der Softwareentwicklung zu verbessern, indem es eine Kombination aus Automatisierung und Überwachung in allen Phasen der Softwareentwicklung verwendet, um die Markteinführungszeit zu verkürzen und die Kundenzufriedenheit zu steigern.
Wichtige Begriffe im Releasemanagement
Um Releasemanagement erfolgreich zu nutzen, müssen Sie die häufig verwendeten Begriffe verstehen.
Entwicklungsarbeitsauftrag: Dies ist ein Arbeitsauftrag für die Entwicklung oder Änderung einer Softwareanwendung oder eines Systems.
DevOps-Team: Da der Sinn von DevOps darin besteht, die Koordination zwischen den Entwicklungs- und Betriebsfunktionen zu verbessern, macht die Erstellung eines separaten Teams den Begriff zu einem Unwort. Trotz des Namens bezieht sich der Begriff in der Regel auf wichtige Teammitglieder der Entwicklungs- und Betriebsseite, deren Aufgabe die Koordination der beiden Funktionen ist.
Installationsarbeitsauftrag: Ähnlich wie ein Entwicklungsarbeitsauftrag ist ein Installationsarbeitsauftrag für die Installation einer Softwareanwendung, eines Systems oder einer Infrastrukturkomponente gedacht.
Produktinhaber: Der Produktinhaber ist der wichtigste Stakeholder in einem Entwicklungsprojekt. Sie repräsentieren in der Regel das Unternehmen oder die (letztendlichen) Benutzer des Produkts und definieren die Vision für ein Produkt.
Projektmanager: Ein Projektmanager übernimmt die Verantwortung für ein einzelnes Produkt. Sie sind für die Definition der Produkt-Roadmap und -vision sowie für die Verhandlungen über die Leistungen verantwortlich. In der Regel sind die Hauptaufgaben eines Projektmanagers auf ein einzelnes Produkt oder eine Produktfamilie beschränkt.
Release: Ein Release besteht aus einer oder mehreren Releaseeinheiten.
Releasemanager: Die Rolle des Releasemanagers besteht darin, alle Elemente, die ein Release umfassen, zu planen, zu koordinieren und zu verwalten. Diese Elemente müssen nicht unbedingt vom gleichen Produkt stammen. Dieser Manager muss beispielsweise auch die Arbeit an allen anderen Produkten koordinieren, die für die Integration in das neue Release entwickelt werden.
Releaserichtlinie: Dies ist eine Reihe von Regeln für die Bereitstellung von Releases in der Live-Betriebsumgebung. Für verschiedene Releases gelten verschiedene Releaserichtlinien, abhängig von Faktoren wie Auswirkungen und Dringlichkeit.
Releaseprotokoll: Ein Releaseprotokoll dokumentiert den Werdegang eines Release, von der Planung bis zum Abschluss des Entwicklungsprozesses.
Releaseeinheit: Dieser Begriff bezieht sich auf eine Reihe von Konfigurationselementen, die ein Team gleichzeitig testet und in die Live-Umgebung freigibt, um genehmigte Änderungen zu implementieren. Ein Konfigurationselement wiederum ist eine Komponente einer Infrastruktur, die unter Konfigurationsmanagement steht. Dies ist der Prozess, mit dem sichergestellt wird, dass die Attribute und die Leistung eines Produkts mit dem Design, den Anforderungen und den betrieblichen Informationen übereinstimmen.
Dienstinhaber: Ein Dienstinhaber übernimmt die grundsätzliche Verantwortung für eine bestimmte IT-Dienstleistung. Sie kümmern sich weniger um den täglichen Betrieb, der für die Erbringung der Dienstleistung erforderlich ist; das ist die Aufgabe eines Dienstmanagers.
Qualitätsmanager: Ein Qualitätsmanager stellt sicher, dass ein Release den festgelegten Standards entspricht. Sie können Releasemanager haben, die ihnen unterstehen.
Wichtige Konzepte im Releasemanagement
Releasemanagement wird manchmal als Superdisziplin beschrieben, da es darum geht, mehrere miteinander verbundene, aber unterschiedliche Disziplinen zu beaufsichtigen, wie der Experte für Konfigurationsmanagement Salman Khwaja anmerkt.
Eine der zentralen Praktiken im Releasemanagement ist das Codemanagement, bei dem Änderungen an Computercode verwaltet werden. Durch die Verwendung von Codemodulen oder Sammlungen von Codezeilen vereinfacht und beschleunigt das Codemanagement die Durchführung von Änderungen an Code sowie andere codebezogene Aktivitäten wie Wartung und Debugging. Eine Art von Codemanagement, die einen wichtigen Aspekt des Releasemanagements darstellt, ist die Versionskontrolle. Dies bezieht sich auf die Verwaltung von Code für verschiedene Releases derselben Software zum Zwecke des Vergleichs und der Referenz. Das Codemanagement folgt vielen Prinzipien der Schriftgutverwaltung.
Um seiner Rolle effektiv nachzukommen, muss ein Releasemanager Arbeitserleichterung und Zusammenarbeit fördern, hauptsächlich zwischen Teams, aber auch innerhalb von Teams. Releasemanager sind in der Regel selbst erfahrene Profis, sodass sie aufgerufen werden können, sich zu beteiligen.
Prozesse und Richtlinien sind entscheidend für effektives Releasemanagement. Probleme werden zwangsläufig auftreten, und wenn sie dies tun, muss es Protokolle geben, um sie zu lösen. Der Releasemanager fungiert auch als Gatekeeper oder Hüter des Produktionscodes. Immer wenn ein Codeartefakt die Organisation verlässt, wissen sie Bescheid.
Über eine Reihe von Releases wird es möglich, Produktivitäts- und Durchsatzmetriken zu messen, damit die Effizienz des Releasemanagements sichtbar wird. Zu den gängigen Metriken gehören Dinge wie Geschwindigkeit und Burn-Down-Rate.
Der Zyklus des Releasemanagements
Das Releasemanagement folgt in der Regel einem klar definierten Pfad. Es beginnt mit der Erstellung eines organisationsweiten Releasezeitplans. Einige Unternehmen veröffentlichen kontinuierlich Software-Updates, andere bevorzugen eher einen festgelegten Zeitplan. Danach wird ein Termin für das Produkt- oder Lösungs-Release festgelegt.
Das Releasemanagement beginnt in der Regel mit der ersten Phase des Entwicklungszyklus, wenn der Releasemanager Anforderungen für Änderungen oder neue Features erhält. Nach Genehmigung der Anforderung entwirft das Team das neue Release und beginnt mit der Planung. Die Entwickler erstellen die neue Software. Nach der Entwicklung wird das Release getestet und das Team kann Änderungen vornehmen, bevor das Release akzeptiert wird. Danach geht das Release in die Bereitstellung über, wo es für die vollständige Nutzung vorbereitet wird. Die Phase nach der Bereitstellung ist die des Supports, in der Bugs oder User-Stories, die das Team hier dokumentiert, als Material für ein neues Release in den Entwicklungszyklus zurückgespeist werden können.
Vorlage für einfachen Releaseplan
Verwenden Sie die folgende Vorlage für einen einfachen Releaseplan. Für besonders komplexe und budgetintensive Projekte stellt das vom Center for Medicaid Services entwickelte Framework für einen Releaseplan, das hier heruntergeladen werden kann, eine gute Referenz dar.
Vorlage für einen einfachen Releaseplan herunterladen — Word
Herausforderungen, die mit dem Releasemanagement angegangen werden können
In der Vergangenheit fehlten vielen Unternehmen Prozesse, um den Releasezyklus zu verwalten. Da sich Probleme jedoch negativ auf das Endergebnis auswirken können, weil Bugs und Abstürze viel Zeit und Geld kosten (sowie Zuverlässigkeit und Reputation), entstand das Releasemanagement als Disziplin zur Annahme häufiger Herausforderungen.
Einige Organisationen haben Schwierigkeiten mit der Bereitstellung von Code von der Entwicklungs- zu Test- und Produktionsumgebungen, und auch wenn dies geringere Auswirkungen auf das Endergebnis hat, ist es dennoch ein Grund zur Sorge für Betriebsmitarbeiter.
An anderer Stelle kann die interne Struktur einer Organisation zu Konflikten zwischen Teams führen. Das Releasemanagement kann die Wogen glätten. Ebenso wächst das Risiko, dass die Arbeit eines Teams das andere stört, wenn viele Teams parallel zusammenarbeiten. Ein effizienter Releasemanagementprozess kann Organisationen helfen, eine Reihe von Problemen zu vermeiden.
Releasemanagement und DevOps in einer Agile-Welt
Organisationen, die ihre Softwareentwicklung auf gängige Agile-Prinzipien stützen, produzieren in der Regel häufiger Releases. Der Agile-Ansatz für Software-Releases wird Continuous Delivery genannt, eine Methode, die darauf abzielt, Code zu erstellen, der jederzeit für den Einsatz bereit ist. Es eliminiert die herkömmlichen Phasen der Integration und Testung fast vollständig und automatisiert den Releaseprozess mit sehr kurzen Zyklen.
Software product development expert and author Jon Quigley of Value Transformation notes that studies have shown an inverse relationship between project size and success. He also says research suggests that customers do not use 45 percent of developed features. These statistics argue for small, focused releases that prioritize features highly valued by customers. “The upshot of all of this has driven deliveries of software or development of increments of software that are small, the smaller the better,” he says.
In der Continuous Delivery bleibt das Releasemanagement das entscheidende Bindeglied zwischen Entwicklung und Produktion. Das Releasemanagement überprüft die Integrität von Code und stellt sicher, dass er wie geplant funktioniert. Agile-Methoden brechen Silos auf, die oft bei Waterfall-Methoden zu sehen sind, aber Agile erfordert eine gründliche Dokumentation, damit die Prozesse klar sind.
Gutierrez von Boeing sagt, dass es viel Verwirrung um Continuous Delivery und eine andere beliebte Praxis, Continuous Deployment, gibt. „Continuous Deployment beschreibt das Konzept, dass jede Änderung in der Codebasis fast umgehend zur Produktion weitergeleitet wird, wenn die Ergebnisse der Pipeline positiv sind. Continuous Delivery beschreibt das Konzept, dass jede Änderung in der Codebasis die Pipeline bis zur Bereitstellung in Nicht-Produktionsumgebungen durchläuft. Das Team findet und löst Probleme sofort, nicht später, wenn es plant, die Codebasis freizugeben. Die Codebasis ist immer auf einem für ein Release geeignetes Qualitätsniveau. Wann die Codebasis für die Produktion freigegeben werden soll, entscheidet das Unternehmen.“, erklärt er.
Um die Codebasis effektiv und effizient für die Produktion freizugeben, verlassen sich Releasemanager auf drei Dinge: Automatisierung, ein DevOps-Mindset und Continuous Integration. Automatisierung bezieht sich hauptsächlich auf Testfunktionen, während ein DevOps-Mindset die Koordination zwischen Entwicklung und Betrieb erheblich verbessert (die Mitarbeiter in der Lieferung und der Infrastruktur können dieselben sein), um den möglicherweise abrupten Übergang von Ersterem zu Letzterem sanfter über die Bühne zu bringen.
Continuous Integration beschreibt die Praxis, dass Entwickler häufig ihre eigenen Arbeitskopien von Code auf eine Mainline aktualisieren – in der Regel etwa einmal am Tag. Continuous Integration beruht auf einem strengen System automatisierter Tests und neigt dazu, Fehler schnell zu beseitigen und den Änderungsprozess zu beschleunigen.
Vorlage für Agile-Releaseplan
Die Agile-Releaseplanung erfolgt vor dem ersten Sprint, sodass Sie sich auf die Releaseziele, Features und die Zuweisung von Ressourcen konzentrieren können. Diese Vorlage für ein Agile-Release ermöglicht Ihnen, alle Ihre Aufgaben aufzulisten, jede Aufgabe einem Sprint zuzuweisen und die Dauer auf der Grundlage von Start- und Enddaten zu berechnen. Außerdem können Sie den Status jeder Aufgabe im Dropdown-Menü auswählen und jedes dazugehörige Ziel definieren.
Vorlage für Agile-Testplan
Bei Agile-Projekten ist die Testphase ein dynamischer, iterativer Prozess, der sicherstellen soll, dass Sie die aktuellsten Informationen verwenden, um Tests zu definieren und Missverständnisse in Sachen Umfang zu vermeiden. Diese Vorlage für einen Testplan bietet Ihnen Platz, um Aktionen, erwartete Ergebnisse, tatsächliche Ergebnisse und ob der Test bestanden wurde oder nicht, nachzuverfolgen.
Vorlage für Agile-Testplan herunterladen – Excel
Releasemanagement mit IT Infrastructure Library/IT Service Management
IT-Dienstmanagement ist eine Obermenge von Aktivitäten, die Organisationen nutzen, um die von ihnen angebotenen IT-Dienstleistungen zu entwerfen, zu planen, zu liefern, zu betreiben und zu steuern. Darunter gibt es eine detaillierte Reihe von Praktiken, die Information Technology Infrastructure Library genannt wird. In Organisationen, die ihren IT-Betrieb mit ITSM und insbesondere mit ITIL verwalten, orientiert sich das Releasemanagement an ITIL-Prinzipien.
In seiner derzeitigen Form, ITIL 2011, besteht ITIL aus fünf Bänden. Das Releasemanagement ist im dritten dieser Bände enthalten, dem Band für den Dienstübergang, der die Bereitstellung von Dienstleistungen für den betrieblichen Gebrauch thematisiert. Wie Sie vielleicht vermuten, zielt der Release- und Bereitstellungsmanagementprozess darauf ab, „die Fortbewegung von Releases zu Test- und Live-Umgebungen zu planen und zu kontrollieren“. Auch das Change-Management ist im dritten Band enthalten.
Releases kommen in ITIL-Organisationen nicht so häufig vor wie in Agile-Organisationen. Releaseprozesse in ITIL werden mit ITSM-Ticketing-Systemen verwaltet, und es wird nicht so viel Wert auf automatisierte Releaseprozesse gelegt. Das heißt nicht, dass sie weniger effektiv sind. Organisationen, die ITIL-Praktiken implementieren, können viel mehr als nur die Effizienz von Releaseprozessen steigern. Sie können auch finanzielle Gewinne erzielen und den Geschäftswert der von ihnen angebotenen Dienstleistungen erhöhen.
Enterprise-Releasemanagement
Enterprise-Releasemanagement (ERM) verwaltet das Gesamtbild von Releases auf organisatorischer Ebene von Entitäten mit großer oder komplexer Software, wie Gesundheitssystemen, großen Unternehmen, Universitäten und dergleichen. ERM befasst sich mit der Koordination einzelner Software-Releases und wie diese in die übergeordneten Pläne, Strategien und Kalender von Organisationen passen.
Warum ist das wichtig? Stellen Sie sich eine Organisation vor, die komplexe Softwaresysteme entwickelt. Mehrere Entwicklungsgruppen arbeiten an verschiedenen Komponenten dieser großen Systeme. Diese Struktur ist intern sinnvoll, da sie Entwicklern ermöglicht, sich zu spezialisieren, den Fokus zu erhöhen und Komponenten Stück für Stück zu entwickeln. Letztendlich müssen die Komponenten jedoch in einem einzigen, nahtlos integrierten System zusammenlaufen. Ohne ein übergreifendes Releasemanagement auf Unternehmensebene fehlt dem IT-Portfolio der Organisation der Zusammenhang.
ERM ermöglicht es Organisationen, große Softwareprodukte einzuführen, die gut als integriertes Ganzes funktionieren, und es hilft ihnen, dies effizient zu tun. ERM-Bemühungen erfordern in der Regel, dass viele Releasemanager parallel arbeiten, damit sie ihre jeweiligen Releases miteinander abstimmen können.
Release Management und die wichtigsten Wissensbereiche nach dem PMI
In einer Abhandlung aus dem Jahr 2000, vorgestellt auf dem Project Management Institute Annual Seminars and Symposium, thematisierte Franck Aguilh die aufkommende Erkenntnis unter Softwareentwicklungsunternehmen, dass es einen Bedarf für eine spezialisierte Disziplin gab, die sich ausschließlich auf die Verwaltung von Releases konzentriert. Der Releasemanager würde diese Rolle anstatt des Projektmanagers übernehmen, da der Projektmanager umfangreichere Prioritäten hat.
Aguilh sagte, dass erfolgreiches Releasemanagement ein Prozess ist, der vier Hauptziele erreicht: pünktliche Bereitstellung, budgetgerechte Bereitstellung, vernachlässigbare Auswirkungen auf bestehende Kunden und die Erfüllung der Anforderungen neuer Kunden, und das alles unter Berücksichtigung des Wettbewerbsdrucks und des technologischen Fortschritts. Er beschrieb das Releasemanagement auch als einen Prozess, der mehrere „wichtige Aufgaben“ umfasst, die von verschiedenen „Organisationen“ zu erledigen sind.
Das Releasemanagement erfordert die Koordination zwischen vielen Abteilungen innerhalb einer Organisation, von denen jede eine spezielle Rolle erfüllt. Die „Organisationen“ von denen Aguilh spricht, reichen vom Vertrieb und Marketing über Forschung und Entwicklung, Betriebs- und Systemtechnik bis hin zu Kundensupport und Rechtsfragen.
„Ein erfolgreiches Release erfordert abteilungsübergreifende Abstimmung.“, sagt Dunbeck von BitTitan. „Entwickler müssen Code an den richtigen Stellen überprüfen. Die QS muss Kontrollen durchführen. Der Betrieb muss Zweigstellen verwalten und den Build für die Bereitstellung vorbereiten. Das sind jedoch nur die technischen Komponenten. Wenn Sie keine Verfahren haben, Änderungen intern zu kommunizieren, werden Ihre Vertriebsmitarbeiter überrascht sein, wenn Sie Kunden Demos mit veränderten Features oder Schaltflächen zeigen. Ihr Support-Team wird nicht in der Lage sein, Fragen zu beantworten, und Ihre Kunden erhalten nicht die Antworten, die sie brauchen, wenn Sie ihnen Änderungen nicht über Versionshinweise, Hilfecenter-Artikel oder auf ähnliche Weise mitgeteilt haben.“, betont sie.
„Der einfachste Weg, diese Probleme zu lösen, besteht darin, die Stakeholder für das Release klar zu identifizieren und sie während des gesamten Projektzyklus häufig einzubeziehen. Jede Organisation hat unterschiedliche Kommunikationspräferenzen. Meetings, ein Chatkanal, eine Wiki-Seite oder einfache E-Mails sind gute Möglichkeiten, um Mitarbeiter auf dem Laufenden zu halten. Das Wichtige ist, eine Kadenz zu identifizieren und dann daran festzuhalten.“, so Dunbeck.
Nach Aguilhs Vision beruht das Releasemanagement zum Teil auf der Anwendung von Projektmanagementprinzipien auf Software-Releases. Dazu gehören die wichtigsten Prozessbereiche des Projektmanagements: Initialisieren, Planen, Durchführen, Kontrollieren und Abschließen.
Aguilh stellte jedoch auch neun Prozesse vor, die speziell für das Releasemanagement sind. Im Folgenden lesen Sie Beschreibungen dieser neun Prozesse sowie die Reihenfolge, in der sie auftreten:
- Funktionale Produktanforderung (Functional Product Request/FPR): Dies ist der Mechanismus für eine „funktionale Gruppe“, um deren Anforderung nach neuen Features oder Funktionen für die Software zu formalisieren.
- Dokumentationsprozess: Das Team setzt Protokolle für den Informationsaustausch für das kommende Release ein.
- Releaseverpackungsprozess: Während dieses Prozesses trifft das Team eine Entscheidung darüber, was in das endgültige Release aufgenommen wird, basierend auf Faktoren wie Marktdruck, Kosten, Umsatz, Entwicklungszeit und Integration.
- Entwicklungsprozess/Änderungskontrollprozess: Diese beiden Schritte laufen parallel und sind selbsterklärend. Während der Entwicklung können Qualitätsgates verwendet werden, um Meilensteine im Entwicklungszyklus anzuzeigen. Die Änderungskontrolle wird in Labor- und Feldtests fortgesetzt, bei denen sowohl überprüft wird, ob die neue Funktionsweise wie erwartet funktioniert, als auch, ob sie bestehende Features beeinträchtigt.
- Schulungsprozess: Dies umfasst die Schulung von Mitarbeitern des technischen Supports, des Direktvertriebs und des Marketings sowie der Telemarketing-Mitarbeiter.
- Kundentests: Dieser Schritt erfolgt über Beta-Releases für Kunden.
- Kundenbenachrichtigungsprozess: In der letzten Phase vor der Bereitstellung müssen Kunden darüber informiert werden, dass in Kürze ein Release ansteht.
- Bereitstellung: Die Bereitstellung selbst ist ein mehrstufiger Prozess, der Schritte vor der Bereitstellung, die tatsächliche Bereitstellung und Schritte nach der Bereitstellung umfasst.
Aguilh merkte an, dass die Prozesse des Releasemanagements ziemlich ähnlich zu denen des Projektmanagements sind. Zum Beispiel sind FPR- und Releaseverpackungen im Grunde eine Berücksichtigung des Umfangs und der Planung, während der Qualitätsprozess das Äquivalent zur Dokumentation, Entwicklung, Änderungskontrolle und Schulung ist. Die Durchführung und Kontrolle entsprechen wiederum Schulungen, Kundentests, Kundenbenachrichtigungen und der Bereitstellung. Der Abschluss ist natürlich mit der Bereitstellung gleichzusetzen. Es zeigt sich daher, dass nützliche Parallelen zwischen Projektmanagement und Releasemanagement gezogen werden können und dass ein effektiver Releasemanager über die gleichen Fähigkeiten wie ein Projektmanager verfügen muss.
Releasemanagementprozesse nach den Phasen des Softwareentwicklungslebenszyklus
Sie haben gesehen, dass Releasemanagementprozesse mit den wichtigsten Prozessen des Projektmanagements in Einklang stehen. Lassen Sie uns nun sehen, wie die Prozesse im Releasemanagement mit den Phasen des Softwareentwicklungslebenszyklus (software development life cycle/SDLC) zu vergleichen sind. Im SDLC gibt es in der Regel sechs Phasen:
- Anforderungserfassung und -analyse
- Design
- Implementierung oder Codierung
- Tests
- Bereitstellung
- Wartung
Während der Entwicklung setzen Manager eine Releaserichtlinie auf, ein Dokument, das den Umfang, die Prinzipien und die Endziele für den Releasemanagementprozess definiert. Es nutzt die strategischen Ziele der Organisation als Basis für den Releasemanagementprozess. Werfen Sie als Beispiel einen Blick auf die Releaserichtlinien der Apache Software Foundation, die Open Source-Softwareprojekte für den Gemeinbedarf fördert.
Releasemanager erstellen Releasepläne auf der Grundlage der Releaserichtlinie. Diese Pläne sind allgemeine Leitfäden für die Bereitstellung mehrerer Releases.
Während der Designphase stellt der Releasemanager sicher, dass die Hardware- und Software-Assets, die das Release unterstützen, entwickelt und konfiguriert werden. Dann beginnt die Codierung.
Während der Implementierung erstellen und konfigurieren die Entwickler den Code. Während der Testphase prüfen Tester den Code in einer betrieblichen Umgebung. Während der Bereitstellung stellen die Entwickler eine Live-Version der Software bereit, und das Qualitätssicherungsteam führt eine Qualitätsprüfung durch, um sicherzustellen, dass das Release den festgelegten Anforderungen entspricht. Wenn das Release die Qualitätsprüfung besteht, ist sie validiert und für die Produktion vorgesehen. Dieses Prüfsiegel wird als Release akzeptiert bezeichnet. Wenn es weiterhin Bugs gibt, lehnt das Team das Release ab. Ein akzeptiertes Release hat einen Rollout-Plan, der die Details der Bereitstellung umfasst, und das Unternehmen informiert Kunden und Endbenutzer über das kommende Release. Schulungen können notwendig sein.
Die Releaseeinheiten werden zur vollständigen Einführung für die Produktion bereitgestellt. Einige Organisationen entscheiden sich dafür, die Implementierung in dieser Phase zu überprüfen, um festzustellen, ob das Release im Live-Betrieb reibungslos funktionieren wird.
In der Wartungsphase führen die Entwickler eine Überprüfung der Release- und Protokollprobleme durch, die im nächsten Release behoben werden sollen.
Vorlage für Releasemanagementzeitplan
Erstellen Sie einen Releasemanagementzeitplan, um die Zeitachse für alle Ihre Releaseaktivitäten zu klären. Verwenden Sie diese Vorlage, um wichtige Leistungen und Fristen nachzuverfolgen, damit alle Beteiligten den Überblick behalten.
Vorlage für Releasemanagementzeitplan herunterladen
Was bedeuten eigentlich: Bereitstellung, Release und Auslieferung
Der Begriff Bereitstellung wird oft synonym zu den Wörtern Release und Auslieferung verwendet, aber sie bedeuten nicht genau dasselbe. Bereitstellung repräsentiert die Installation oder Ausführung einer neuen Version von Code auf einem Server – mit der Software „live“ sein. Diese Bereitstellung erfolgt eher auf einem Testserver als auf einem Produktionsserver. Ein Release ist die Softwareform dieser neuen Version. Es ist für eine Zielgruppe jenseits der Entwickler gedacht, entweder für andere Mitarbeiter in der Organisation oder für Kunden. Ein Release verfügt in der Regel über eine Versionsnummer. Wenn ein Kunde ein Release bereitstellt, wird dies im Allgemeinen als Installation der Software bezeichnet. Die Auslieferung beschreibt den Prozess des Transports von Code durch den gesamten Erstellungs-, Test- und Bereitstellungskreislauf.
Die Bereitstellung ist sowohl im Lebenszyklus der Softwareentwicklung als auch im Releasemanagementzyklus ein entscheidender Punkt. Die Bereitstellung ist der Moment, in dem die neue Softwareversion zur Verwendung verfügbar ist und das neue Release live geht. In den Worten von Paul Jackson von der University of Edinburgh School of Informatics bedeutet die Implementierung, „Software aus den Händen der Entwickler in die Hände der Benutzer zu legen“. Für diese Phase benötigen Endbenutzer möglicherweise eine Schulung.
Jackson stellt fest, dass die Bereitstellung oft problematisch ist: Mehr als 50 Prozent der in Auftrag gegebenen Software wird nicht verwendet, vor allem, weil die Bereitstellung fehlschlägt. Wenn bei der Bereitstellung Probleme in der Software auftreten, leiten die Entwickler einen „Rollback“ auf die vorherige Version ein, bis die Probleme behoben sind.
Jackson berichtet auch, dass 80 Prozent der Ausgaben für in Auftrag gegebene Software bei und nach der Bereitstellung entstehen. Dies bedeutet natürlich nicht unbedingt, dass die Bereitstellung selbst ein Fehler ist; es kann durchaus sein, dass Probleme in der Entwicklung erst bei der Bereitstellung auftauchen.
Aber manchmal ist die Bereitstellung das Problem. Vielleicht ist der Kunde einfach nicht auf eine Änderung in der Produkterfahrung vorbereitet, wie es große Systemreleases oft erfordern. Mangelnde Softwareübernahme kann auch auf eine Reihe anderer Faktoren zurückzuführen sein: Die Hardware des Kunden kann nicht mit dem neuen Release umgehen; der Kunde hat Probleme bei der Installation der Software; mangelnde Schulung stellt ein Hindernis dar; oder die Neuinstallation „bricht“ die andere, bereits vorhandene Software des Kunden.
Viele direkt mit der Bereitstellung verbundenen Probleme können durch Automatisierung und Schulung gelöst werden, sodass der Endbenutzer nicht über Dinge wie Systemkompatibilität nachdenken muss. Die Anwendung von bewährten Vorgehensweisen im Releasemanagement macht diese Lösungen zum Standardbetriebsverfahren.
Was ist ein Releasebereitstellungsprozess?
Der Prozess der Releasebereitstellung konzentriert sich darauf, die Software in einer Live-Umgebung betriebsbereit zu machen. Damit dies geschieht, muss die Software Tests durchlaufen und vom Produktinhaber oder einem anderen Stakeholder des Unternehmens offiziell akzeptiert werden. Während des Bereitstellungsprozesses erhalten Benutzer eine Schulung für das Softwareupdate und Teammitglieder führen eine Bewertung oder Überprüfung dazu durch, wie es abschneidet und wie die Bereitstellung gelaufen ist.
Bewährte Vorgehensweisen im Releasemanagement
098Im Releasemanagement sind bewährte Vorgehensweisen der Leitfaden, der von Unternehmen erstellt und verfeinert wird, die ITIL bereits erfolgreich implementiert haben. Die Leitfäden sind Eigentum des britischen Cabinet Office und werden von diesem veröffentlicht. ITIL-Releasemanagementprozesse wurden von Raumfahrtprogrammen, Gesundheitsdiensten, Banken und Unterhaltungsunternehmen mit guten Ergebnissen eingesetzt. Die Leitfäden sollten von Organisationen an ihre eigenen Anforderungen und Kapazitäten angepasst werden. Denken Sie jedoch daran: Sie sind ein Ausgangspunkt, kein Evangelium.
Obwohl das Releasemanagement während des Übergangs von der Entwicklung zur Produktion am wichtigsten ist, beginnt es mit der Planung von Releases während der Entwicklung. Zum Beispiel ist es eine gute Idee, ein Änderungsgremium zu gründen, das den Wandel im gesamten Unternehmen überwacht. Es ist auch ratsam, ein einzelnes Releasemanagementsystem zu entwerfen, das im gesamten SDLC verwendet werden kann.
In ähnlicher Weise fördert die Erstellung einer Checkliste für Releaseprozesse die Transparenz und das gemeinsame Verständnis des Releasemanagementprozesses und der Art und Weise, wie er geschäftlichen Wert schafft. Ergänzend zu Atul Gawandes Buch „Checklist Manifesto“ macht es die Verwendung einer Checkliste auch einfacher, den Releaseprozess zu kontrollieren, insbesondere wenn es Metriken gibt, die überwacht werden müssen. Darüber hinaus ist es hilfreich, einen aktiven Senior Sponsor zu haben.
“The most common pitfall with release management is not following a release checklist,” says Chris Harding, a Release Manager at Microsoft. “The details in a release checklist are key. You may be having an off day, or something may distract you while you’re configuring a product, but the checklist never lies,” he points out.
Harding glaubt, dass ein einfacher Fehler, der durch eine Checkliste hätte vermieden werden können, hinter der Veröffentlichung mehrerer Videospieltitel auf der Website von Walmart Canada im Mai 2018 vor deren offizieller Vorstellung auf einer Branchenkonferenz steckte. „Wahrscheinlich war der Zeitpunkt falsch für die Produktseiten festgelegt, und niemand hat es bemerkt, bevor alles veröffentlicht wurde. In der medizinischen Gemeinschaft retten Checklisten Leben. Releasemanagement ist nicht so dramatisch, aber es kann Ihren Job retten.“
Vorlage für eine Software-Releasecheckliste
Um alle Ihre Releaseaktivitäten nachzuverfolgen, sollten Sie eine Checkliste verwenden. Diese Vorlage ist in den Formaten für Microsoft Word und Excel verfügbar und bietet Platz für Notizen und den Status des Marketings, der Produktentwicklung, der QS, der Technik/DevOps, der Benutzererfahrung, des technischen Supports, der Dienstleistungen und der rechtlichen Aufgaben. Passen Sie die Vorlage auf die Anforderungen Ihres Projekts an.
Vorlage für eine Software-Releasecheckliste herunterladen
Einige bewährte Vorgehensweisen ergeben sich aus gesundem Menschenverstand. Continuous Integration verbessert beispielsweise die Qualität des späteren Releases, indem Fehler schnell erkannt werden. Es ist auch keine gute Idee, ein Release an einem Freitag herauszugeben, da so keine Zeit für die Fehlerbehebung während der Arbeitswoche bleibt, wenn doch Fehler auftreten. Es lohnt sich auch, ein Release dann herauszugeben, wenn gerade nicht viel los ist – Sie sollten herausfinden, wann Ihre Kunden aktiv sind – damit Sie bessere Schadensbegrenzung betreiben können, wenn etwas schief geht. Eine weitere Option ist ein stufenmäßiger Rollout, bei dem Features nur einer kleinen Anzahl von Benutzern gleichzeitig zur Verfügung gestellt werden. Natürlich müssen Datenbanken auch vor Releases gesichert werden.
Denken Sie schließlich daran, dass die Implementierung eines Releasemanagementprozesses an und für sich ein Prozess ist. Schritt für Schritt kann das Releasemanagement iteriert und Automatisierung erreicht werden. Versuchen Sie nicht, den Prozess zu erzwingen.
Software-Tools für das Releasemanagement
Software-Tools können den Releasemanagementprozess beschleunigen und erleichtern.
Zum Beispiel wurden moderne Softwareprodukte entwickelt, um einige Plattformen zu unterstützen, von Internetbrowsern bis hin zu Anwendungsservern und Betriebssystemen. Daher müssen sie vor der Veröffentlichung in diesen Umgebungen getestet werden. Die Erstellung und Wartung aller für das Testen erforderlichen Umgebungen stellt ein Problem dar. Aber es gibt eine einfache Lösung: die Verwendung virtualisierter und Cloud-Dienste wie Selenium und SmartBear, die den Prozess der Bereitstellung von Konfigurationen für die Zielplattformen vereinfachen, indem für jede eine simulierte Testumgebung erstellt wird.
“A common challenge is automating the release but not having good automated testing in place,” notes Brian White, Senior Solutions Architect at custom software developer Small Footprint. “If you don’t have confidence in the quality of your release, it doesn’t matter how fast it can be deployed if it’s always going to break when someone starts using it,” he says.
Um den Releasemanagementprozess zu vereinfachen, bieten Softwareentwicklungsplattformen und Releasemanagementsysteme wie GitHub, Jira und viele andere eine enge Integration der Komponenten, die für ein erfolgreiches Release erforderlich sind. Diese können während des gesamten SDLC verwendet werden, von der Releaseplanung bis zur Produktion.
Solche Tools sind in der Regel basierend auf den Anforderungen des Unternehmens skalierbar und zentralisieren Aktualisierungs- und Administrationsfunktionen, was besonders nützlich ist, wenn sie über das Internet als SaaS-Tools (Software-as-a-Service) zugänglich sind. Die besten Tools unterstützen auch das Testen und die Bereitstellung von Verwaltungskomponenten sowie das Change-Management und die Integration mit Dienstmanagement-Komponenten von Drittanbietern, die ein End-to-End-Liefersystem ermöglichen. Suchen Sie nach Tools, die den ITIL V3-Richtlinien des IT Service Management Forum entsprechen.
Tools, die eine zumindest teilweise Automatisierung des Releaseprozesses ermöglichen, sind eine große Hilfe. Es kann möglich sein, die Softwareweiterleitung bis in die Produktion zu automatisieren oder eine halbautomatische Reihe von Prozessen mit Genehmigungen und On-Demand-Bereitstellungen einzurichten.
Weitere nützliche Features sind, unter anderem, die Möglichkeit, alle Änderungen verschiedener Versionen nachzuverfolgen, sodass es leicht ist, die Ursache von Problemen zu ermitteln und eine Struktur zu haben, die den Ärger eines Rollback auf die letzte funktionierende Version erspart. Das Protokollieren von Anwendungsfeedback, eine Funktion, die für kommende Versionen in einen Arbeitsbestand verschoben werden kann, ist ebenfalls hilfreich.
Darüber hinaus sollten Sie Tools in Betracht ziehen, die Continuous Integration und Continuous Deployment unterstützen. Continuous Deployment geht einen Schritt weiter als Continuous Delivery, um Änderungen sofort beim Durchlaufen der Produktionspipeline umzusetzen. Dieser Ansatz beschleunigt den Feedback-Prozess und steigert die Effizienz erheblich.
Metriken und KPIs im Releasemanagement
Sobald ein Releasemanagementprozess ausgereift ist, kann sich ein Releasemanager Leistungsmetriken zuwenden, um den Prozess zu verbessern. Schauen wir uns ein paar davon an:
- Ausfallzeit von Releases: Dies ist die erste wichtige Metrik. Jedes Softwarerelease birgt das Risiko von Ausfallzeiten, deren Dauer von wenigen Minuten bis zu einigen Stunden oder sogar Tagen reichen kann. Ausfallzeiten sind an sich nichts Schlechtes; oft sind sie sogar notwendig. Abgesehen davon ist es wichtig, die verschiedenen Arten von Ausfallzeiten unterscheiden zu können. Geschätzte Ausfallzeiten sind zum Beispiel notwendig und Teil des Releasezeitplans, und es ist eine gute Idee, diese mit den tatsächlichen Ausfallzeiten zu vergleichen, die nach der Veröffentlichung gemessen werden. Es gibt auch ungeplante Ausfallzeiten, die, wenn sie über mehrere Releases hinweg vorkommen, ein Zeichen dafür sein können, dass tiefergehende Probleme nicht behoben werden.
- Art und Priorität von Releases: Jedes Release wird als groß, klein oder irgendwo dazwischen kategorisiert und jedem wird eine Priorität zugewiesen: hoch, mittel oder niedrig. Betrachten Sie den Typ und die Priorität Ihrer Releases. Es sollte eine gute Mischung von Releases verschiedener Größen und Prioritäten sein. Zu viele große Releases für das gleiche Produkt können auf ernsthafte Probleme in der Qualitätssicherung hindeuten, während zu viele Releases mit hoher Priorität darauf hindeuten, dass Ihr Team permanent Probleme lösen muss, was sehr stressig sein kann.
- Die Anzahl der pünktlichen Releases: Da ein pünktliches Release nicht sicher ist, geht es genauso um Verzögerungen bei Releases. Es gibt einige interessante Informationen zu gewinnen. Haben manche Entwicklungsteams beispielsweise mehr verspätete oder pünktliche Releases als andere? Gibt es ein Muster für verspätete oder pünktliche Lieferungen, das auf der Priorisierung von Releases basiert? Was sind die Ursachen für wiederholt verspätete Releases?
Sie können auch einige interessante Metriken auf Unternehmensebene nachverfolgen. Dazu gehören die Größe von Enterprise-Releases aus drei verschiedenen Perspektiven: Projekte, Systembereitstellungen und Features. Ein weiterer nützlicher Satz von Metriken verfolgt die Zahlen hinter Projekten, Systemen und Features, die „de-scoped“ wurden. (De-Scoping liegt vor, wenn etwas, das für ein Release vorgesehen ist, das Release-Gate nicht passiert hat und daher aus dem Enterprise-Release entfernt wird, um dieses nicht zurückzuhalten.)
Fallstudien im Releasemanagement
Wir haben uns bisher mit viel Theorie befasst und Sie fragen sich vielleicht, wie Releasemanagement in Wirklichkeit funktioniert. Bei Microsoft ist dies gut zu sehen.
Microsofts Core Services Engineering (CSE) stützt sich auf eine Kombination aus Continuous Integration, Continuous Delivery und einer in der Cloud gehosteten Plattform namens Visual Studio Team Services (VSTS). Ihr Entwicklungsansatz, den sie als „modern engineering“ bezeichnen, basiert auf den Prinzipien der Agile-Entwicklung und DevOps.
Wenn Sie einen Blick darauf werfen, wie Microsoft seine Entwicklung um Continuous Delivery herum strukturiert, werden Sie verstehen, wie sehr es von einem besseren Releasemanagement profitiert. Microsoft-Softwareentwickler konzentrieren sich auf die Entwicklung eines minimal funktionsfähigen Produkts, die Frühanwender anzieht und es Entwicklern ermöglicht, Feedback für spätere Releases zu sammeln.
Microsoft-Entwickler können Code jederzeit in jeder Bereitstellungsumgebung ausprobieren und nutzen Komponentisierung, um die Erstellung des Codes zu erleichtern. Im Rahmen des Releasemanagementprozesses von Microsoft können sie unbeaufsichtigte Builds und unbeaufsichtigte Bereitstellungen austesten, die nur wenige Minuten in Anspruch nehmen, ohne um Ressourcen zu konkurrieren. Außerdem ist der Validierungsprozess für die Bereitstellung automatisiert.
CSE übernimmt auch die Agile-Prinzipien des iterativen Designs und des Rapid-Prototyping und nutzt Automatisierung, um Testzeiten zu beschleunigen. Das bedeutet, dass das CSE Releasezyklen beschleunigen, Probleme schnell beheben und kontinuierliche Aktualisierungen und Verbesserungen in kleineren Blöcken liefern kann – Letzteres reduziert auch das Risiko, da weniger Zeit für die Entwicklung jedes Features aufgewendet wird.
Es sind auch nicht nur Technologieunternehmen, die von Releasemanagement profitieren. Zwischen 2008 und 2010 hat die IT-Abteilung der zentralen Wertpapierverwahrung der Türkei eine umfassende Automatisierung des Konfigurationsmanagements, des Abhängigkeitsmanagements, des Infrastrukturmanagements, des Change-Managements, des Datenbankmanagements und des Anwendungskonfigurationsmanagements durchgeführt, um Probleme bei Releases „vollständig zu beseitigen“, Releasezeiten zu verkürzen und bereitstellungsbedingte Fehler radikal zu reduzieren.
Bei United Airlines hat ein Releasemodell mit vier Schritten für die Planung, Koordination, Durchführung und Automatisierung – mit umfangreichen Daten als Basis – dem Unternehmen dabei geholfen, von einem auf Tabellenkalkulation beruhenden Releasemanagement zu einem zentralen System für die Releasenachverfolgung und -management mit Dashboards überzugehen.
Wie man das Releasemanagement verbessert
Um das Releasemanagement in Ihrer Organisation zu verbessern, müssen Sie den aktuellen Stand Ihres Releasemanagementprozesses verstehen. Sie sollten dies auf zwei Arten tun: quantitativ und qualitativ.
Im quantitativen Sinne sollten Sie einige grundlegende Metriken zusammenstellen, darunter die durchschnittlichen Releasezeiten, die Art und Priorität von Releases, die Anzahl der Fehler und die Anzahl der verzögerten Releases. Diese dienen sowohl dazu, den aktuellen Stand des Releasemanagements zu identifizieren als auch Leistungs-Baselines zu ermitteln.
Sprechen Sie im qualitativen Sinne mit den Personen, die Teil des Releasemanagementprozesses sind, insbesondere dort, wo die Entwicklung Berührungspunkte mit dem Betrieb hat, und finden Sie heraus, was sie denken. Ihre Gesprächspartner werden in der Lage sein, auf Sachverhalte hinzuweisen, die nicht in den Zahlen auftauchen.
Sie können das Releasemanagement in den Griff bekommen, indem Sie einen regelmäßigen Releasezyklus einrichten, der zur Schaffung von Konsistenz beiträgt. (Dies wird natürlich nicht für alle Releases möglich sein, aber Sie können dies für große, im Voraus geplante Releases tun.) Setzen Sie unkomplizierte Releaseprozesse ein, anstatt von Anfang an eine Kultur zu entwickeln. So können Sie die Infrastruktur für Releases frühzeitig einrichten und bei Bedarf testen und überarbeiten.
Im Laufe der Zeit werden die Prozesse, die gut funktionieren, zur Standardpraxis werden. Basierend auf Ihrer ersten Umfrage zum Releasemanagement können Sie jetzt damit beginnen, strengere Qualitätsanforderungen zu stellen und die Effizienzmaßstäbe zu erhöhen. Sie können die Auswirkungen von Releases auf Ihre Benutzer minimieren, indem Sie Ausfallzeiten verhindern und Regressionstests durchführen. In dieser Phase können Sie auch die Regularisierung und Automatisierung von Prozessen wie Tests und Verifizierungen in Betracht ziehen.
Eine wahrhaft kollaborative Release-Kultur braucht Zeit und eine Release-Infrastruktur, um zu entstehen. Sie können diese Kultur fördern, indem Sie Interesse an Ihren Mitarbeitern zeigen und in Tools und Techniken für das Releasemanagement investieren, welche die Mitarbeiter ermutigen, einen ganzheitlichen Blick auf den gesamten Releasemanagementprozess zu werfen.
Die Verbesserung der Kommunikation und des Zugriffs auf Informationen wird die Koordination fördern. Lassen Sie Mitarbeiter wissen, dass Releases besser werden, denn es ist wichtig, positive Erwartungen zu setzen. „Eine Herausforderung für Teams ist es, wenn sie Releases als rein technische Hürde betrachten und eine gute Kommunikation innerhalb des Unternehmens und mit den Stakeholdern vernachlässigen. Um dies zu überwinden, sollten Sie sicherstellen, dass alle im Team die Ziele und Risiken verstehen, und denken Sie daran, Endbenutzern Änderungen mitzuteilen, um Überraschungen zu vermeiden.“, sagt White von SmallFootprint.
Die Aufgabe des Releasemanagers
Wenn Sie das Gefühl haben, dass die Entwickler und den Betrieb zu einem Endziel zu führen und eine Produktionsfrist zu erreichen, nach einer interessanten Aufgabe klingt, sollten Sie in Betracht ziehen, Releasemanager zu werden.
Ein Releasemanager muss sich einen Weg durch eine komplexe Landschaft von Projekten, Entwicklungsmethoden, Infrastruktur und Stakeholdern bahnen und gleichzeitig die Bemühungen aller Personen koordinieren, die an einem Enterprise-Release beteiligt sind. Releasemanager sind auch führenden Managern in der Organisation unterstellt, bis hin zum CEO (obwohl das Releasemanagement in reiferen Organisationen wahrscheinlich ein eigenständiger Bereich ist), und sie nehmen einen Großteil der Verantwortung auf sich, wenn ein Release schief geht.
Harding von Microsoft sagt, dass es für Releasemanager wichtig sei, über umfassende Projektmanagement-Fähigkeiten zu verfügen. „Anderen Projekt-Stakeholdern Schulung und Zugriff zur Verfügung zu stellen, ist der Schlüssel, um die Abhängigkeit von einer Person zu verringern. Releasemanager haben in der Regel eine Reihe ziemlich spezieller Problemlösungsfähigkeiten, aber sie können sich auf andere PMs stützen, die die Verantwortung für Elemente der Produktkonfiguration und des Produktprozesses übernehmen.“, erklärt er.
Was sind also die Qualitäten eines guten Releasemanagers? Sie sind bestens mit der Arbeitsweise der Entwicklung und des Betriebs vertraut – das heißt sowohl die technischen Arbeitsweisen als auch die Art und Weise, wie die Mitarbeiter zusammenarbeiten. Sie verfügen über ausgezeichnete Managementfähigkeiten, wenn es um Arbeit, Zeit und besonders um Menschen geht. Sie setzen auf Qualität, Effizienz und Prozesse. Sie sind Befürworter der Automatisierung, und auf der technischen Seite müssen sie sachkundige Betreiber von Quellcode-Repositories sein. Außerdem sind sie mit den unzähligen projekt-, funktions- und abteilungsübergreifenden Abhängigkeiten vertraut, die ein Enterprise-Release definieren.
Sie wissen auch, was sie im Release-Management zu glauben haben (und was nicht).
Mythen über Software-Releases und Releasemanagement
Es gibt eine Menge konventioneller Weisheiten über das Releasemanagement, aber wie viel davon ist glaubhaft? Zu unserem Glück haben Slinger Jansen und Sjaak Brinkkemper, zwei Forscher der Utrechter Universität in den Niederlanden, bereits versucht, diese Frage durch einen Vergleich von Kosten und Wert zu beantworten . Sie fanden heraus, dass es viele Mythen und Irrglauben gibt.
Mythos 1: Kunden wollen auf dem neuesten Stand sein. Tatsächlich kümmern sich Kunden nur dann um Aktualisierungen, wenn diese nützliche Funktionen bereitstellen. Wenn ein Release ihre Erfahrung nicht besser macht, ist es ihnen egal.
Mythos 2: Kunden müssen (aus der Perspektive des Anbieters) auf dem neuesten Stand sein. In diesem Fall ist es Anbietern wichtiger, dass Kunden die neueste Version einer Software verwenden, als den Kunden selbst. Wie wir bereits wissen, führen Kunden Aktualisierungen durch, wenn sie möchten, und sind andernfalls mit älteren Versionen zufrieden.
Mythos 3: Das neueste Release ist immer das Beste. Je nach Anwendungsfall eines Kunden kann ein altes (oder sehr altes) Release gut funktionieren, während ein neues erfordern könnte, dass er Zeit investiert, um mit einer neuen Benutzeroberfläche oder einem neuen Feature umzugehen.
Mythos 4: Fehlerbehebungen können bis zum nächsten großen Release warten. Leider kommt „das nächste große Release“ selten pünktlich. Bis es dann kommt, bleiben die Probleme bestehen und plagen Kunden.
Mythos 5: Problemumgehungen müssen unbedingt vermieden werden. Manchmal haben Benutzer keine Einwände gegen einfache Problemumgehungen, wenn es sich bei der Alternative um eine teure und zeitaufwändige Aktualisierung auf ein neues Release handelt.
Mythos 6: Kunden wollen immer neue Features. Wenn die neuen Features ihren etablierten, komfortablen Workflows im Weg sind, wollen sie diese nicht.
Mythos 7: Häufige Releases sind schlecht. Solange die Releases nicht jedes Mal für Ihre externen Kunden sind, sind häufige Releases nicht schädlich. Häufige Releases können den Feedback-Zyklus verkürzen, beschränken diese aber größtenteils auf interne Benutzer und Pilotkunden.
Mythos 8: Ein stiller Kunde ist ein glücklicher Kunde. Es sind die Kunden, die sich in den frühen Phasen der Nutzung am häufigsten an den Support wenden, die sich als am zufriedensten mit dem Produkt erweisen. Reichen Sie Ihren Kunden die Hand.
Mythos 9: Kunden lesen Versionshinweise. Natürlich nicht. Sie tun es, wenn sie müssen – das heißt, wenn sie eine begrenzte Auswahl haben und professionelle Software auswählen – aber sie bevorzugen gezielte Informationen, die zusammenfassen, was sie als bestimmte Kundengruppe wissen müssen.
Mythos 10: Viele verschiedene Releases auf dem Markt zu haben, ist schlecht. Dies kann ein Problem sein, wenn der Anbieter Kunden, die ältere Versionen verwenden, kontinuierlichen Support bietet, aber selbst dann ist es ein Zahlenspiel. Eine kleine Anzahl von Kunden mit der älteren Version zu haben, ist kein unüberschaubares Problem.
Große Trends im Bereich Releasemanagement
Agile-Praktiken und Automatisierung werden allmählich zu zentralen Grundsätzen des Releasemanagements, und das aus gutem Grund. Automatisierung verkürzt Releasezeiten und kann das Fehlerrisiko erheblich reduzieren. Agile-Praktiken treiben die Übernahme von Build-Automatisierung, Testautomatisierung, Bereitstellungsautomatisierung und Feedback-Automatisierung voran, welche allesamt die Belastung für das Entwicklungsteam reduzieren.
„Sowohl Automatisierung als auch die Verwendung virtualisierter/Cloud-Plattformen ermöglichen und unterstützen einen weiteren Trend im Releasemanagement: Continuous Delivery“, sagt Gabriel Gutierrez, Releasemanager bei Boeing. „Mit Continuous Delivery wird jede neue Softwareüberarbeitung automatisch eingebaut, getestet und für die Bereitstellung vorbereitet, wodurch Ideen schnell in die Realität umgesetzt werden. Continuous Delivery ermöglicht häufigere Bereitstellungen, was häufigeres Feedback von Kunden bedeutet. Infolgedessen wird weniger Zeit verschwendet, weil Sie schnell erfahren, ob Sie die Änderungen vornehmen, die Ihre Kunden benötigen und wollen.“, fügt er hinzu.
Ein weiterer Trend, der an Fahrt aufgenommen hat, ist die Verwendung verteilter Versionskontrollsysteme (distributed version control systems/DVCS) wie GIT, Mercurial und Perforce, die die Zusammenarbeit von Teams grundlegend verändern. DVCS ermöglicht es Benutzern, eigenständige Repositories auf lokalen Computern mit Vollversionshistorien zu führen. Diese Funktion ermöglicht es, offline zu arbeiten und Änderungen nur an der lokalen Einrichtung vorzunehmen. Entwickler können Änderungen vornehmen, ohne den zentralen Code zu beeinträchtigen, was sich hervorragend zum Experimentieren eignet.
Es wird angenommen, dass die DevOps-Kultur und -Praxis in größeren Unternehmen zum Standard werden wird, wobei die Automatisierung aller Phasen ein erreichbares Ziel ist. Start-ups werden die DevOps-Methode in der Zwischenzeit wohl von Anfang an übernehmen. Dies liegt zum Teil daran, dass DevOps, wenn richtig ausgeführt, weniger Ausfallzeiten, schnellere Wiederherstellungsraten und eine größere Anzahl von Bereitstellungen ermöglicht, was wiederum eine Verringerung der (sehr kostspieligen) Ausfallzeiten bedeutet. Mit der zunehmenden Übernahme von DevOps wird auch der Prozess der Linksverschiebung, also wenn automatisierte Tests und Leistungsüberwachung früher im Lebenszyklus stattfinden und die Sicherheitsverifizierung Teil der Lieferpipeline wird, häufiger verwendet werden.
„Obwohl es kein neuer Trend ist, haben sich häufigere und schnellere Bereitstellungen von einer technischen Herausforderung zu einer Erwartung von Stakeholdern entwickelt.“, fügt White von Small Footprint hinzu. „Da die Stakeholder besser über die Möglichkeiten und Vorteile häufigerer Bereitstellungen informiert sind, geben sie sich nicht mehr mit wochenlangem Warten zwischen den Releases zufrieden und drängen Entwicklungsteams dazu, mehr Releases zu veröffentlichen. Wenn das Team über keine solide Infrastruktur für Continuous Integration/Continuous Delivery verfügt, kann dies das Team stark belasten.“, schließt er ab.
Quigley sagt, dass die erfolgreiche Umsetzung dieser schnellen und klar definierten Stufen von Softwareinhalten „ein Maß an Sorgfalt in Bezug auf das Konfigurationsmanagement und die Nachverfolgung des Wachstums eines Produkts im Laufe der Zeit erfordert, da mehr Iterationen an den Kunden geliefert werden.“
Weitere Ressourcen zum Releasemanagement
Eine technischere Einführung in das Releasemanagement finden Sie in diesem White Paper von Jez Humble von ThoughtWorks Studios. Sobald Sie diese gelesen haben, wartet ein großes Aufgebot an Ressourcen für das Releasemanagement von Electric Cloud auf Sie, die sich mit den Besonderheiten befassen.
Wenn Sie über Releasemanagement als Beruf nachdenken und bereits mit Agile arbeiten, schauen Sie bei diesem kurzen Kurs von Jan-Erik Sandberg über Pluralsight vorbei. Wenn Sie denken, dass es auch eine gute Idee ist, sich in ITIL zertifizieren zu lassen, bietet Pink Elephant offizielle ITIL-Zertifizierungskurse an, beginnend mit den Grundlagen.
Schließlich, wenn Sie einfach nur sofort in das Releasemanagement einsteigen möchten, werfen Sie einen Blick darauf, wie Harvard Information Technology dies macht.
Verbessertes Releasemanagement mit Smartsheet für die Softwareentwicklung
Befähigen Sie Ihr Team, über sich selbst hinauszuwachsen – mit einer flexiblen Plattform, die auf seine Bedürfnisse zugeschnitten ist und sich anpasst, wenn sich die Bedürfnisse ändern. Mit der Plattform von Smartsheet ist es einfach, Arbeiten von überall zu planen, zu erfassen, zu verwalten und darüber zu berichten. So helfen Sie Ihrem Team, effektiver zu sein und mehr zu schaffen. Sie können über die Schlüsselmetriken Bericht erstatten und erhalten Echtzeit-Einblicke in laufende Arbeiten durch Rollup-Berichte, Dashboards und automatisierte Workflows, mit denen Ihr Team stets miteinander verbunden und informiert ist. Es ist erstaunlich, wie viel mehr Teams in der gleichen Zeit erledigen können, wenn sie ein klares Bild von der geleisteten Arbeit haben. Testen Sie Smartsheet gleich heute kostenlos.