„Releasemanagement“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Versionsgeschichte interaktiv durchsuchen
[gesichtete Version][gesichtete Version]
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
Inhalt gelöscht Inhalt hinzugefügt
VisuellWikitext
Keine Bearbeitungszusammenfassung
Artikel gen. übera. mit vielen Zit. und Lit.
Markierungen: Visuelle Bearbeitung Begriffsklärungsseiten-Links
Zeile 1: Zeile 1:
{{Quellen}}

[[Datei:releasemngt.jpg|mini|350px|Zusammenhänge verschiedener Prozesse im Release Management]]
[[Datei:releasemngt.jpg|mini|350px|Zusammenhänge verschiedener Prozesse im Release Management]]
Das '''Releasemanagement''' (oder ''Freigabemanagement''<ref>{{Literatur |Autor=Fabian Wolf |Titel=Fahrzeuginformatik: Eine Einführung in die Software- und Elektronikentwicklung aus der Praxis der Automobilindustrie |Verlag=Springer Fachmedien Wiesbaden |Ort=Wiesbaden |Datum=2018 |ISBN=978-3-658-21223-0 |DOI=10.1007/978-3-658-21224-7 |Online=http://link.springer.com/10.1007/978-3-658-21224-7 |Abruf=2022-07-28}}</ref> bzw. ''Release Engineering'') ist traditionell eine Managementaktivität, die sich mit der Freigabe bzw. dem Übergang von Entwicklungsständen in einen operativen Zustand befasst.<ref>{{Internetquelle |autor=R.J. Cloutier (Editor in Chief) |url=https://www.sebokwiki.org/wiki/Deploying,_Using,_and_Sustaining_Systems_to_Solve_Problems |titel=Deploying, Using, and Sustaining Systems to Solve Problems - SEBoK |werk=The Guide to the Systems Engineering Body of Knowledge (SEBoK), v. 2.6 |hrsg=The Trustees of the Stevens Institute of Technology |datum=2022-07-28 |sprache=en |abruf=2022-07-28}}</ref> Es ist Bestandteil bei der [[Produktentwicklung|Entstehung]] von Komponenten, Systemen oder Produkten. Beispiele sind [[Entwicklungsstadium (Software)|Software]], Hardware (Elektrik oder Elektronik), mechanischer Bauteile, Computersysteme und die IT<ref>{{Literatur |Autor=Dominic Müller, Joachim Herbst, Markus Hammori, Manfred Reichert |Titel=IT Support for Release Management Processes in the Automotive Industry |Sammelwerk=Business Process Management |Band=4102 |Verlag=Springer Berlin Heidelberg |Ort=Berlin, Heidelberg |Datum=2006 |ISBN=978-3-540-38901-9 |DOI=10.1007/11841760_26 |Seiten=368–377 |Online=http://link.springer.com/10.1007/11841760_26 |Abruf=2022-07-28}}</ref>. Es unterstützt die übergeordnete Leitung dieser Bereiche.
Das '''Releasemanagement''' (auch '''Release-Management''', englische Schreibweise ''release management'') ist ein Prozess, der sich ursprünglich aus den Erfahrungen des [[Produktmanagement]]s der [[Software-Industrie]] ableitete, welcher die Bündelung von Konfigurations-Änderungen zu einem Release oder Versionspaket und deren ordnungsgemäße Eingliederung in der Infrastruktur sicherstellte. Releasemanagement bedeutet die Planung und Durchführung der Veröffentlichung, von der Idee bzw. den ersten Anforderungen bis zum Erreichen des Endbenutzers. Es interagiert somit zwischen [[Änderungswesen|Change-]] und [[Konfigurationsmanagement]]. Es ist Teil des [[ITSM]] bzw. des [[ITIL]]-[[Service Management]]s.


== Hintergrund ==
Das Releasemanagement hat zur Aufgabe, sicherzustellen, dass eine erwartete Anforderung an eine Veränderung in einem Prozess mit einem vertretbaren Risiko in der geforderten Zeit erfolgreich umgesetzt werden kann. Anpassungen im Geschäftsbereich auf sich ständig verändernde äußere Anforderungen erfordern eine permanente Neukonfiguration der Systeme, die die zugrunde liegenden Prozesse steuern. Gleichzeitig erhöht in einer komplexen Umgebung dieser evolutive Prozess der dauerhaften Neukonfiguration von Systemen das Risiko, lebenswichtige Geschäftsprozesse durch Fehlkonfiguration zu stören, unvorhergesehen zu beeinflussen oder ganz zum Stillstand zu bringen. Ein Unternehmen rechtfertigt den Einsatz eines Releasemanagement mit der Reduktion der teilweise erheblichen Kosten durch etwaige Prozess-Störungen, die durch notwendige konfigurative Veränderungen hervorgerufen werden können. Das Releasemanagement hat die Aufgabe, die Risiken der Unterbrechung von Geschäftsprozessen bei Konfigurationsänderungen bestehender Systeme, die durch schlecht geplante oder nicht ausreichend getestete Systemkonfigurationen hervorgerufen werden, zu mindern.
Unter Freigabemanagement versteht man die Bündelung und Bereitstellung von Änderungen von Versionsständen zu einem sog. Release oder Versionspaket.


Der Begriff findet häufig Verwendung in der Softwareentwicklung, jedoch bezieht sich die Aufgabe ganz allgemein auch auf z. B. Elektronikentwicklung (vgl. [[Bemusterung (Technik)|Musterstände]]), Prototypen, Systeme oder generelle Produkte. Freigabemanagement ist eine Erweiterung der [[Versionsverwaltung]]. Des Weiteren ist die Eingliederung eines freigegeben Objektes in eine Infrastruktur oder Produktion bedeutend.<ref>{{Literatur |Autor=Kim H. Pries |Titel=Project management of complex and embedded systems : ensuring product integrity and program quality |Verlag=CRC Press |Ort=Boca Raton |Datum=2009 |Sprache=en |ISBN=978-1-4200-7206-8 |Seiten=215 ff.}}</ref> Als Beispiel kann man sich eine Software (oder Anteile davon) vorstellen, die bei einem Auftragnehmer kodiert wurde und nach Abschluss aller Tests an einen Auftraggeber übergeben wird, welcher diese in seinem Produkt weiterverwendet.
== Aufgaben des Releasemanagements ==


Das Freigabemanagement interagiert mit dem [[Veränderungsmanagement|Veränderungs]]- und [[Konfigurationsmanagement]], sowie [[Integrationsmanagement]]. Es ist jedoch eine eigenständige Disziplin. Es bezieht außerdem Erfahrungen aus dem [[Produktmanagement]]s generell.
Das Releasemanagement hat folgende Aufgaben:
* Festlegung des funktionellen Umfangs
* Festlegung des genauen Zeitplans einer Releasefreigabe in Abstimmung mit dem Change- bzw. [[Produktmanagement]]
* [[Qualitätskontrolle]] zur Überwachung der Einhaltung der Kriterien, die im Rahmen des Change- bzw. Produktmanagements für eine Releaseerstellung festgelegt wurden
* Dokumentation des Umfangs und der Änderungen, dabei insbesondere Beschreibung der für die Rückwärts[[Kompatibilität (Technik)|kompatibilität]] relevanten Eigenschaften
* Verwaltung der Versionshistorie (''[[Versionierung]]''), damit Sicherstellung der Reproduzierbarkeit


== Releaseanforderung ==
== Ziele ==
Das Freigabemanagement erfüllt verschiedene Ziele, wie z.B.:


=== Verfügbar machen von Entwicklungsständen ===
Releaseanforderungen werden zunächst vom [[Change Management (ITIL)|Change-Management]] erfasst. Das Change-Management formuliert in der Regel auch den 'Use Case' und kümmert sich auch um den (je nach Risiko-Relevanz teilweise recht komplexen) Genehmigungsprozess. Anschließend wird die eigentliche Aufgabe der Durchführung eines Changes, also die 'Executive', an das Releasemanagement übergeben. Daraus resultiert oft die Meinung, das Releasemanagement sei ein Teilbereich des Change-Managements. Das Releasemanagement ist jedoch nach Praxis-Erfahrung aus dem [[ITIL]]-Bereich bewusst kein Teilbereich des Change-Managements. Unternehmen, die dies nicht berücksichtigen und Releasemanagement im Change-Management integrieren, werden recht schnell in interne Konfliktsituationen der Verantwortlichkeiten kommen, in denen die wichtigen Elemente der Risikoeinschätzung, der Planung und Qualitätskontrolle meistens aus dem notwendigen Gleichgewicht kommen. Somit stellt das Releasemanagement auch sicher, dass ein Release die erwartete Anforderung mit einem vertretbaren Risiko in der geforderten Zeit umsetzen kann. Die ITIL v3 berücksichtigt diesen Umstand und hat deshalb das Releasemanagement explizit als eigenständige Prozesseinheit definiert. In ITIL 4 ist das Release Management auch eine eigene Service Management Practice.
Als Grundziel dient das Freigabemanagement dem Bereitstellen von Entwicklungsständen. Das Ziel ist dabei die Abnahme (Übernahme) durch einen Kunden oder andere Partei. Es bildet damit die prozessuale Schnittstelle, z. B. beim Übergang von Software zu Hardware oder eines allgemeinen Produktes vom Ende der Entwicklungsphase zum Endverbraucher.


=== Risikominimierung von Änderungen ===
== Releaseplanung ==
Änderungen sind allgegenwärtiger Bestandteil in einer Produktentwicklung. Effektives Releasemanagement kann die negativen Folgen von mangelhaften Spezifikationen, Designs, Implementierungen oder Tests und deren Einfluss auf andere Prozesse, Systeme oder Geschäftspartner hemmen.


Hinweis: Das eigentliche [[Veränderungsmanagement]] beschäftigt sich explizit mit der Kontrolle von Änderungen innerhalb eines Produktlebenszyklus bzw. dessen Teilabschnitte. Das [[Anforderungsmanagement]] ist für ebenfalls als eigenständige Disziplin zu erwähnen.
Die Planung erstellt das Kerngerüst, die eigentliche Blaupause eines gesamten Releaseprojektes.


=== Erfüllung von Standards und Normen ===
== Releaseentscheidung ==
Verschiedene Normen fordern Arbeitsprodukte, welche u.a. vom Releasemanagement generiert und erfüllt werden müssen. Beispiel: [[Automotive SPICE]], dort SPL.2 Product Release.


=== Einfluss auf Produktqualität ===
Der Releasemanager entscheidet, wann ein System als Release zur Weitergabe freigegeben werden kann. Er muss dabei darauf achten, dass das System frei von schwerwiegenden Fehlern, also produktionssicher ist. In der traditionellen [[Entwicklungsstadium (Software)#Release Candidate|Softwareentwicklung]] ist dies der Fall, wenn der Entwicklungsprozess das Stadium [[Entwicklungsstadium (Software)#Release Candidate|Release Candidate]] erreicht.
Eine Freigabe steht auch in Bezug zu einer [[Verifizierung und Validierung]] einer Komponente, Systems oder Produktes. Sie dient als formelle Grundlage dafür.


== Risikoanalyse ==
== Aktivitäten ==


Einige Aktivitäten, die für eine Freigabe notwendig sind, sind z. B.:
Risiken sind immer mit Geschäftsperspektiven abzugleichen. Dabei wird ein Restrisiko teilweise bewusst in Kauf genommen um z. B. aufgrund von zu späten Releases mit höherer Qualität keinen geschäftlichen Vorteil, den man durch ein früheres Releasedatum erreicht, zu verlieren.
* Festlegung des Umfangs einer Freigabe (in Abstimmung mit dem Projektteam, dem Auftraggeber, etc.)
* Festlegung des genauen Zeitplans einer Freigabe in Abstimmung mit dem Change- bzw. [[Produktmanagement]]
* [[Qualitätskontrolle]] der Freigabe anhand von festgelegten Kriterien bzw. Checklisten
* Dokumentation des Inhalts der Freigabe, dabei insbesondere Beschreibung der für die Rückwärts[[Kompatibilität (Technik)|kompatibilität]] relevanten Eigenschaften
* Verwaltung der Versionshistorie (''[[Versionierung]]''), damit Sicherstellung der Reproduzierbarkeit


== Ablauf, Bausteine und Phasen ==
== Qualitätskontrolle ==


=== Koordination und Anforderungen ===
Die Qualitätskontrolle eines Releases ist eines der wichtigsten Elemente der Sicherstellung der Change Objectives, also der Frage
Die Aufgabe wird meist von einem eigenständigen Releasemanager bzw. Projektleiter oder sogar Team<ref name=":0">{{Internetquelle |autor=Tyler Cipriani |url=https://diff.wikimedia.org/2021/10/07/how-the-wikimedia-foundation-deploys-code/ |titel=How the Wikimedia Foundation deploys code |werk=Diff |datum=2021-10-07 |sprache=en-US |abruf=2022-07-28}}</ref> durchgeführt. Inhaltlich bedeutet dies die Planung und Ausführung von Freigaben. Dabei werden festgelegte Umfänge (Anforderungen und Kriterien) berücksichtigt. Ein Verfügbar machen (intern oder extern) für den Endbenutzer bzw. Zielsystem ist dabei Hauptbestandteil der Aufgabe.
* was will man ursprünglich mit der Änderung einer Konfiguration aus der Geschäftsperspektive erreichen und
* stimmt das Ergebnis auch mit den Anforderungen überein?
Realisiert wird dies durch entsprechende Testpläne, durch Simulationen und Entwicklung und Test der Strategien zu Notfallsituationen.


Ein Zusammenspiel erfolgt mit dem [[Veränderungsmanagement]] ([[Change Management (ITIL)]]), [[Integrationsmanagement]], [[Testmanagement]] ([[Akzeptanztest|Akzeptanztests]]), [[Marketing]], etc. bzw. anderen Unternehmenseinheiten. Die meisten an einer Produktenwicklung beteiligten Einheiten werden über das Freigabemanagement angesprochen bzw. es werden Ergebnisse aus den einzelnen Bereichen eingefordert. Unabhängig von einer Freigabe läuft die Produktenwicklung meist weiter. Jedoch kann eine Freigabe (je nach Umfang und Zielsetzung) auch einen Abschluss bzw. Neubeginn einer Projektphase darstellen ([[Meilenstein (Projektmanagement)|Meilensteine]]).
== Releaseerstellung ==


=== Planung ===
Wenn die reine Entwicklung abgeschlossen ist, bedeutet das aber nicht gleichzeitig eine Veröffentlichung. Dazu müssen oft noch weitere Schritte erfolgen:
Die Planung der Freigabe ist als eigenständiges Projekt zu verstehen. Es müssen Zeitpläne erstellt werden, Umfänge abgeschätzt und festgelegt, Kommunikation mit [[Stakeholder|Stakeholdern]] etc. bewältigt werden, alles was notwendig ist um eine Freigabe zu ermöglichen.


=== Entscheidung ===
Der Releasemanager entscheidet, wann ein System als Release zur Weitergabe freigegeben werden kann. Durch eine geeignete Release-Strategie muss dabei darauf geachtet werden, dass das System frei von schwerwiegenden Fehlern, also produktionssicher ist. In der traditionellen [[Entwicklungsstadium (Software)#Release Candidate|Softwareentwicklung]] ist dies meist der Fall, wenn der Entwicklungsprozess das Stadium [[Entwicklungsstadium (Software)#Release Candidate|Release Candidate]] erreicht.

=== Risikoanalyse ===
Das Freigabemanagement integriert die Arbeitsprodukte des Risikomanagement, wie z. B. Risikoanalysen, die für den betreffenden Release Gültigkeit haben. Zu jeder Freigabe werden diverse Risiken einer Freigabe abgeschätzt. Diese können sich von anderen Risiken unterscheiden und sind speziell zugeschnitten.

=== Qualitätskontrolle ===
Das Freigabemanagement integriert Test- und Prüfberichte (bereitgestellt von der Qualiätsabteilung) für den jeweiligen Release. Weiterhin spielen im Falle von Software auch Ergebnisse aus der [[Informationssicherheit]] eine Rolle (z. B. [[Penetrationstest]]) und können Einfluss auf eine Freigabe nehmen.

=== Bereitstellung der eigentlich Freigabe ===
Das Freigabemanagement arbeitet entlang der Produktentwicklung und bereitet meist eine zyklische Herausgabe vor. Wenn die reine Entwicklung abgeschlossen ist, bedeutet das aber nicht gleichzeitig eine Veröffentlichung. Dazu müssen oft noch weitere Schritte erfolgen:
* Erstellung der Konfigurationsstände, welche alle Komponenten beinhaltet
* Erstellung der Konfigurationsstände, welche alle Komponenten beinhaltet
* Zusammenstellung und Bezeichnung sowohl des Quellcodes als auch sämtlicher Datendateien
* Zusammenstellung und Bezeichnung von Software-Quellcode, Hardwaredesigns, technischen Zeichnungen oder anderer Elemente
* Bereitstellung von Konfigurationsdateien, Benutzerhandbüchern, technischer Dokumentation, …
* Bereitstellung von Benutzerhandbüchern, technischer Dokumentation, usw.
* Bereitstellung/Vertrieb ([[Datenträger]], E-Mail, [[Download]], …)
* Bereitstellung/Vertrieb der Komponente, der Software, Hardware, etc.
* Ausbildung und Vorbereitung der Mitarbeiter, die das System nutzen
* Hilfestellung für die Ausbildung und Vorbereitung der Mitarbeiter

* Ausbildung und Vorbereitung der Mitarbeiter, die das System pflegen
=== Dokumentation ===
Die Dokumentation dient z. B. der späteren Nachproduktion oder [[Rückverfolgbarkeit (Anforderungsmanagement)|Rückverfolgung]] von speziellen Releases für einzelne Kunden oder Plattformen.

Es sollte eine komplette Beschreibung der gesamten [[Systemumgebung]] und des zugrunde liegenden Systems (Programme, Versionen, Dokumente, Beschreibungen, [[Anleitung]]en, generelle Artefakte) erstellt werden.

== Zusammenhang mit Softwareentwicklung ==

=== Methodologie ===
Software-Freigabemanagement verändert sich als Aufgabe ebenso wie die Softwareentwicklung selbst. Im Falle von Groß-Softwareprojekten existieren eigene Release-Teams (bzw. Release-Engineering Teams) und eigene Abläufe, die sich je nach Projekt aufstellen, anpassen und optimieren. Als Beispiel arbeitet das Release-Team der Wikimedia Foundation ([[MediaWiki]]) mit sog. ''Release-Trains'' (Freigabezügen), welche wöchentlich stattfinden.<ref name=":0" /> Je nach Software-Kontext (z. B. Open Source Software<ref>{{Internetquelle |autor=Stefano Zacchiroli |url=http://blog.ieeesoftware.org/2016/08/release-management-in-open-source.html |titel=Release management in Open Source projects |sprache=en |abruf=2022-07-28}}</ref> oder Mobile Apps<ref>{{Internetquelle |autor=Federica Sarro |url=http://blog.ieeesoftware.org/2016/03/release-management-of-mobile-apps.html |titel=Release Management of Mobile Apps |sprache=en |abruf=2022-07-28}}</ref>) ergeben sich eigenständige Anforderungen und Herausforderungen. Die hohe Komplexität (Datenmengen, Datenbanken, Schnittstellen, Benutzereingaben/UIs, Zielgeräte, Probleme usw.) von Software spiegelt sich u.a. auch bei der Freigabe wieder. Dies kann am Beispiel der [[Corona-Warn-App]] detailreich nachvollzogen werden.

=== Werkzeuge, Services, Methodologien ===
Für Releasemanagement stehen verschiedene Werkzeuge zur Verfügung, je nach Produkt und Industrie.

''Hinweis: Ein reines Werkzeug zur Versionskontrolle dient noch nicht zum eigentlichen Releasemanagement. Anteilig am Releasemanagement sind auch die sog. [[Versionshinweise]].''

==== Beispiele ====

* [[DevOps]]<ref>{{Literatur |Autor=Abhinav Krishna Kaiser |Titel=Release Management in DevOps |Sammelwerk=Reinventing ITIL® in the Age of DevOps |Verlag=Apress |Ort=Berkeley, CA |Datum=2018 |ISBN=978-1-4842-3975-9 |DOI=10.1007/978-1-4842-3976-6_10 |Seiten=271–295 |Online=http://link.springer.com/10.1007/978-1-4842-3976-6_10 |Abruf=2022-07-28}}</ref>
* [[GitHub]]
* [[GitLab]]
** ''Hinweis: Diese auf [[Git]] basierten Plattformen stellen eine erweiterte Versionskontrolle mit Freigabemethodiken dar.''
* [[Kontinuierliche Integration]] (CI/CD)
** ''Hinweis: Kontinuierliche Integration kann als eine Art Weiterentwicklung der einfachen Versionskontrolle verstanden werden. Es kann ebenso automatische Releases verwalten. Es ist jedoch meist eine Kernfrage des Releasemanagement die genauen Inhalte (Features) und Defekte zu definieren und koordinieren.''
* [[Apache Subversion]] (SVN)
** ''Hinweis: Einige Softwareprojekte oder -produkte haben eigene Software-Release Methoden zu ihrem Produkt oder für Entwicklung, die sich am Produkt beteiligen wollen.<ref>{{Internetquelle |url=https://subversion.apache.org/docs/community-guide/releasing.html |titel=Apache Subversion - Community Guide - Making Subversion Releases |abruf=2022-07-28}}</ref>''

== Neuartige oder angrenzende Entwicklungen ==

* [[Over-the-Air-Update|Over-the-Air-Updates]] sind sowohl in der Telekommunikation, [[Internet der Dinge]], als auch Automobilindustrie<ref>{{Internetquelle |autor=Wolfgang Rudschies |url=https://www.adac.de/rund-ums-fahrzeug/reparatur-pflege-wartung/reparatur-rueckruf/updates-over-the-air/ |titel=Updates over the air: Wie das Auto per Software aufgefrischt wird |werk=ADAC |hrsg=Allgemeiner Deutscher Automobil-Club e.V. (ADAC) |datum=27.07.2021 |abruf=2022-07-28}}</ref> teils im produktiven Einsatz und fordern ein robustes und geeignetes Freigabemanagement.
* Im [[Cloud Computing]] werden sog. ''Feeds'' genutzt, um Pakete zu bündeln und verteilen.<ref>{{Internetquelle |autor=ramiMSFT |url=https://docs.microsoft.com/en-us/azure/devops/artifacts/concepts/feeds |titel=What are feeds? - Azure Artifacts |sprache=en-us |abruf=2022-07-28}}</ref>
* Ein anderes Instrument sind [[Containervirtualisierung|Container]], speziell [[Docker (Software)|Docker]].
* In den Wissenschaften, wo häufig mit Publikationen gearbeitet wird, kann ein sog. [[Peer-Review]] als eine Freigabe verstanden werden.
* Die NASA bietet seine für die Raumfahrt entwickelte Software der Öffentlichkeit an und hat dafür ein eigenständiges Programm aufgelegt.<ref>{{Internetquelle |url=https://software.nasa.gov/ |titel=Home {{!}} NASA Software Catalog |abruf=2022-07-28}}</ref>

== Zusammenhang Informationstechnologie und ITIL ==
Das Freigabemanagement dient dem [[Service-Management|Service Management]] und ist Teil des [[ITSM|IT-Service-Management]] (ITSM).<ref>{{Internetquelle |autor=Stefan Kempter, Andrea Kempter |url=https://wiki.de.it-processmaps.com/index.php/Release_Management |titel=Release Management {{!}} IT Process Wiki |hrsg=IT Process Maps GbR |sprache=en |abruf=2022-07-28}}</ref> Es ist seit ITIL v3 eine eigenständige Prozesseinheit.

Im Zusammenhang mit ITIL stehen das geforderte [[ITIL Definitive Hardware Library|Definitive Hardware Library]] und [[ITIL Definitive Software Library|Definitive Software Library]].<ref>{{Internetquelle |url=https://advisera.com/20000academy/blog/2014/10/28/itil-definitive-software-library-definitive-hardware-store/ |titel=ITIL Definitive Software Library and Definitive Hardware Store |sprache=en-US |abruf=2022-07-28}}</ref> Die Bedeutung ist jeweils die Archivierung (logische Verwaltung) von technischen bzw. Softwarekomponenten eines Unternehmens. Das DSL wurde nach der Veröffentlichung von ITIL v3 zu DML (Definitive Media Library) umbenannt.

== Normen ==

* [[ISO/IEC 20000]]<ref>{{Internetquelle |autor=14:00-17:00 |url=https://www.iso.org/cms/render/live/en/sites/isoorg/contents/data/standard/07/06/70636.html |titel=ISO/IEC 20000-1:2018 |abruf=2021-02-10 |sprache=en}}</ref>
* [[Automotive SPICE]]

== Literatur ==


== Releasedokumentation ==
=== Artikel ===


* {{Literatur |Autor=Pratik K. Biswas |Titel=Autonomic Software Release Management for Communications Networks |Sammelwerk=2007 10th IFIP/IEEE International Symposium on Integrated Network Management |Verlag=IEEE |Ort=Munich, Germany |Jahr=2007 |ISBN=978-1-4244-0798-9 |DOI=10.1109/INM.2007.374782 |Seiten=179–188}}
Die Dokumentation von Releases ist z. B. zur späteren Nachproduktion oder [[Rückverfolgbarkeit (Anforderungsmanagement)|Rückverfolgung]] von speziellen Releases für einzelne Kunden oder Plattformen sehr wichtig.
* {{Literatur |Autor=Murali Ramakrishnan |Titel=Software release management |Sammelwerk=Bell Labs Technical Journal |Band=9 |Nummer=1 |Datum=2004-05-11 |Sprache=en |DOI=10.1002/bltj.20015 |Seiten=205–210}}


=== Modernere Lehrtexte ===
Die [[Dokumentation]] sollte eine komplette Beschreibung der gesamten [[Systemumgebung]] und des zugrunde liegenden Systems (Programme, Versionen, Dokumente, Beschreibungen, [[Anleitung]]en, …) enthalten, um eine spätere Wiederherstellung zu vereinfachen.


* {{Literatur |Autor=Hans-Bernd Kittlaus |Titel=Software Product Management: The ISPMA®-Compliant Study Guide and Handbook |Verlag=Springer Berlin Heidelberg |Ort=Berlin, Heidelberg |Jahr=2022 |ISBN=978-3-662-65115-5 |DOI=10.1007/978-3-662-65116-2}}
== DHL – Definitive Hardware Library ==
* {{Literatur |Autor=Gerard O’Regan |Titel=Concise Guide to Software Engineering |Verlag=Springer International Publishing |Ort=Cham |Jahr=2017 |Sprache=en |Reihe=Undergraduate Topics in Computer Science |ISBN=978-3-319-57749-4 |DOI=10.1007/978-3-319-57750-0}}
* {{Literatur |Autor=Michael T. Nygard |Titel=Release it! design and deploy production-ready software |Auflage=Second edition |Verlag=Pragmatic Bookshelf |Ort=Raleigh, North Carolina |Jahr=2018 |Reihe=The pragmatic programmers |ISBN=978-1-68050-239-8}}
* {{Literatur |Autor=Stephen Rylander |Titel=Patterns of Software Construction: How to Predictably Build Results |Verlag=Apress |Ort=Berkeley, CA |Jahr=2022 |ISBN=978-1-4842-7935-9 |DOI=10.1007/978-1-4842-7936-6}}


=== Klassische Werke ===
Die Archivierung zur Logistischen Verwaltung der technischen Komponenten eines Unternehmens.


* {{Literatur |Autor=Michael E Bays |Titel=Software Release Methodology |Verlag=Prentice Hall |Ort=Philadelphia, PA |Jahr=1999 |Sprache=en}}
== DSL – Definitive Software Library ==
Die Archivierung zur Logistischen Verwaltung der Softwarekomponenten eines Unternehmens.
DSL wurde nach der Veröffentlichung von ITIL v3 zu DML (Definitive Media Library).


* {{Literatur |Autor=C. Michael Pilato, Ben Collins-Sussman, Brian W. Fitzpatrick, Kathrin Lichtenberg, C. Michael Pilato |Titel=Versionskontrolle mit Subversion: Software-Projekte intelligent koordinieren |Auflage=3. Aufl., komplett überarb. und aktualisiert |Verlag=O’Reilly |Ort=Beijing Köln |Jahr=2009 |ISBN=978-3-89721-897-0 |Online=https://svnbook.red-bean.com}}
== Zertifizierung ==
* {{Literatur |Autor=Tobias Wassermann |Titel=Versionsmanagement mit Subversion: Installation, Konfiguration, Administration ; [Repository-Verwaltung und -Administration, Serverkonfiguration von Apache und svnserve, grafische Oberflächen für Subversion, vollständige Befehlsreferenz] |Auflage=1. Aufl |Verlag=mitp |Ort=Heidelberg |Jahr=2006 |Reihe=Programmierung |ISBN=978-3-8266-1662-4}}
[[ISO/IEC 20000]] Release-Management als Teilbereich des ISO/IEC-20000-Standards.<ref>{{Internetquelle |autor=14:00-17:00 |url=https://www.iso.org/cms/render/live/en/sites/isoorg/contents/data/standard/07/06/70636.html |titel=ISO/IEC 20000-1:2018 |abruf=2021-02-10 |sprache=en}}</ref>


== Siehe auch ==
== Siehe auch ==


* [[Software Engineering]]
* [[Software Engineering]]
* [[Versionshinweise]]
* [[Änderungsmanagement]]
* [[Softwarequalität]]
* [[Softwarequalität]]
* [[Anforderungsmanagement]]


== Quellen ==
== Einzelnachweise ==
<references />
<references />
[[Kategorie:Softwaretechnik]]
[[Kategorie:Softwaretechnik]]
[[Kategorie:IT-Management]]

Version vom 28. Juli 2022, 23:35 Uhr

Zusammenhänge verschiedener Prozesse im Release Management

Das Releasemanagement (oder Freigabemanagement[1] bzw. Release Engineering) ist traditionell eine Managementaktivität, die sich mit der Freigabe bzw. dem Übergang von Entwicklungsständen in einen operativen Zustand befasst.[2] Es ist Bestandteil bei der Entstehung von Komponenten, Systemen oder Produkten. Beispiele sind Software, Hardware (Elektrik oder Elektronik), mechanischer Bauteile, Computersysteme und die IT[3]. Es unterstützt die übergeordnete Leitung dieser Bereiche.

Hintergrund

Unter Freigabemanagement versteht man die Bündelung und Bereitstellung von Änderungen von Versionsständen zu einem sog. Release oder Versionspaket.

Der Begriff findet häufig Verwendung in der Softwareentwicklung, jedoch bezieht sich die Aufgabe ganz allgemein auch auf z. B. Elektronikentwicklung (vgl. Musterstände), Prototypen, Systeme oder generelle Produkte. Freigabemanagement ist eine Erweiterung der Versionsverwaltung. Des Weiteren ist die Eingliederung eines freigegeben Objektes in eine Infrastruktur oder Produktion bedeutend.[4] Als Beispiel kann man sich eine Software (oder Anteile davon) vorstellen, die bei einem Auftragnehmer kodiert wurde und nach Abschluss aller Tests an einen Auftraggeber übergeben wird, welcher diese in seinem Produkt weiterverwendet.

Das Freigabemanagement interagiert mit dem Veränderungs- und Konfigurationsmanagement, sowie Integrationsmanagement. Es ist jedoch eine eigenständige Disziplin. Es bezieht außerdem Erfahrungen aus dem Produktmanagements generell.

Ziele

Das Freigabemanagement erfüllt verschiedene Ziele, wie z.B.:

Verfügbar machen von Entwicklungsständen

Als Grundziel dient das Freigabemanagement dem Bereitstellen von Entwicklungsständen. Das Ziel ist dabei die Abnahme (Übernahme) durch einen Kunden oder andere Partei. Es bildet damit die prozessuale Schnittstelle, z. B. beim Übergang von Software zu Hardware oder eines allgemeinen Produktes vom Ende der Entwicklungsphase zum Endverbraucher.

Risikominimierung von Änderungen

Änderungen sind allgegenwärtiger Bestandteil in einer Produktentwicklung. Effektives Releasemanagement kann die negativen Folgen von mangelhaften Spezifikationen, Designs, Implementierungen oder Tests und deren Einfluss auf andere Prozesse, Systeme oder Geschäftspartner hemmen.

Hinweis: Das eigentliche Veränderungsmanagement beschäftigt sich explizit mit der Kontrolle von Änderungen innerhalb eines Produktlebenszyklus bzw. dessen Teilabschnitte. Das Anforderungsmanagement ist für ebenfalls als eigenständige Disziplin zu erwähnen.

Erfüllung von Standards und Normen

Verschiedene Normen fordern Arbeitsprodukte, welche u.a. vom Releasemanagement generiert und erfüllt werden müssen. Beispiel: Automotive SPICE, dort SPL.2 Product Release.

Einfluss auf Produktqualität

Eine Freigabe steht auch in Bezug zu einer Verifizierung und Validierung einer Komponente, Systems oder Produktes. Sie dient als formelle Grundlage dafür.

Aktivitäten

Einige Aktivitäten, die für eine Freigabe notwendig sind, sind z. B.:

  • Festlegung des Umfangs einer Freigabe (in Abstimmung mit dem Projektteam, dem Auftraggeber, etc.)
  • Festlegung des genauen Zeitplans einer Freigabe in Abstimmung mit dem Change- bzw. Produktmanagement
  • Qualitätskontrolle der Freigabe anhand von festgelegten Kriterien bzw. Checklisten
  • Dokumentation des Inhalts der Freigabe, dabei insbesondere Beschreibung der für die Rückwärtskompatibilität relevanten Eigenschaften
  • Verwaltung der Versionshistorie (Versionierung), damit Sicherstellung der Reproduzierbarkeit

Ablauf, Bausteine und Phasen

Koordination und Anforderungen

Die Aufgabe wird meist von einem eigenständigen Releasemanager bzw. Projektleiter oder sogar Team[5] durchgeführt. Inhaltlich bedeutet dies die Planung und Ausführung von Freigaben. Dabei werden festgelegte Umfänge (Anforderungen und Kriterien) berücksichtigt. Ein Verfügbar machen (intern oder extern) für den Endbenutzer bzw. Zielsystem ist dabei Hauptbestandteil der Aufgabe.

Ein Zusammenspiel erfolgt mit dem Veränderungsmanagement (Change Management (ITIL)), Integrationsmanagement, Testmanagement (Akzeptanztests), Marketing, etc. bzw. anderen Unternehmenseinheiten. Die meisten an einer Produktenwicklung beteiligten Einheiten werden über das Freigabemanagement angesprochen bzw. es werden Ergebnisse aus den einzelnen Bereichen eingefordert. Unabhängig von einer Freigabe läuft die Produktenwicklung meist weiter. Jedoch kann eine Freigabe (je nach Umfang und Zielsetzung) auch einen Abschluss bzw. Neubeginn einer Projektphase darstellen (Meilensteine).

Planung

Die Planung der Freigabe ist als eigenständiges Projekt zu verstehen. Es müssen Zeitpläne erstellt werden, Umfänge abgeschätzt und festgelegt, Kommunikation mit Stakeholdern etc. bewältigt werden, alles was notwendig ist um eine Freigabe zu ermöglichen.

Entscheidung

Der Releasemanager entscheidet, wann ein System als Release zur Weitergabe freigegeben werden kann. Durch eine geeignete Release-Strategie muss dabei darauf geachtet werden, dass das System frei von schwerwiegenden Fehlern, also produktionssicher ist. In der traditionellen Softwareentwicklung ist dies meist der Fall, wenn der Entwicklungsprozess das Stadium Release Candidate erreicht.

Risikoanalyse

Das Freigabemanagement integriert die Arbeitsprodukte des Risikomanagement, wie z. B. Risikoanalysen, die für den betreffenden Release Gültigkeit haben. Zu jeder Freigabe werden diverse Risiken einer Freigabe abgeschätzt. Diese können sich von anderen Risiken unterscheiden und sind speziell zugeschnitten.

Qualitätskontrolle

Das Freigabemanagement integriert Test- und Prüfberichte (bereitgestellt von der Qualiätsabteilung) für den jeweiligen Release. Weiterhin spielen im Falle von Software auch Ergebnisse aus der Informationssicherheit eine Rolle (z. B. Penetrationstest) und können Einfluss auf eine Freigabe nehmen.

Bereitstellung der eigentlich Freigabe

Das Freigabemanagement arbeitet entlang der Produktentwicklung und bereitet meist eine zyklische Herausgabe vor. Wenn die reine Entwicklung abgeschlossen ist, bedeutet das aber nicht gleichzeitig eine Veröffentlichung. Dazu müssen oft noch weitere Schritte erfolgen:

  • Erstellung der Konfigurationsstände, welche alle Komponenten beinhaltet
  • Zusammenstellung und Bezeichnung von Software-Quellcode, Hardwaredesigns, technischen Zeichnungen oder anderer Elemente
  • Bereitstellung von Benutzerhandbüchern, technischer Dokumentation, usw.
  • Bereitstellung/Vertrieb der Komponente, der Software, Hardware, etc.
  • Hilfestellung für die Ausbildung und Vorbereitung der Mitarbeiter

Dokumentation

Die Dokumentation dient z. B. der späteren Nachproduktion oder Rückverfolgung von speziellen Releases für einzelne Kunden oder Plattformen.

Es sollte eine komplette Beschreibung der gesamten Systemumgebung und des zugrunde liegenden Systems (Programme, Versionen, Dokumente, Beschreibungen, Anleitungen, generelle Artefakte) erstellt werden.

Zusammenhang mit Softwareentwicklung

Methodologie

Software-Freigabemanagement verändert sich als Aufgabe ebenso wie die Softwareentwicklung selbst. Im Falle von Groß-Softwareprojekten existieren eigene Release-Teams (bzw. Release-Engineering Teams) und eigene Abläufe, die sich je nach Projekt aufstellen, anpassen und optimieren. Als Beispiel arbeitet das Release-Team der Wikimedia Foundation (MediaWiki) mit sog. Release-Trains (Freigabezügen), welche wöchentlich stattfinden.[5] Je nach Software-Kontext (z. B. Open Source Software[6] oder Mobile Apps[7]) ergeben sich eigenständige Anforderungen und Herausforderungen. Die hohe Komplexität (Datenmengen, Datenbanken, Schnittstellen, Benutzereingaben/UIs, Zielgeräte, Probleme usw.) von Software spiegelt sich u.a. auch bei der Freigabe wieder. Dies kann am Beispiel der Corona-Warn-App detailreich nachvollzogen werden.

Werkzeuge, Services, Methodologien

Für Releasemanagement stehen verschiedene Werkzeuge zur Verfügung, je nach Produkt und Industrie.

Hinweis: Ein reines Werkzeug zur Versionskontrolle dient noch nicht zum eigentlichen Releasemanagement. Anteilig am Releasemanagement sind auch die sog. Versionshinweise.

Beispiele

  • DevOps[8]
  • GitHub
  • GitLab
    • Hinweis: Diese auf Git basierten Plattformen stellen eine erweiterte Versionskontrolle mit Freigabemethodiken dar.
  • Kontinuierliche Integration (CI/CD)
    • Hinweis: Kontinuierliche Integration kann als eine Art Weiterentwicklung der einfachen Versionskontrolle verstanden werden. Es kann ebenso automatische Releases verwalten. Es ist jedoch meist eine Kernfrage des Releasemanagement die genauen Inhalte (Features) und Defekte zu definieren und koordinieren.
  • Apache Subversion (SVN)
    • Hinweis: Einige Softwareprojekte oder -produkte haben eigene Software-Release Methoden zu ihrem Produkt oder für Entwicklung, die sich am Produkt beteiligen wollen.[9]

Neuartige oder angrenzende Entwicklungen

  • Over-the-Air-Updates sind sowohl in der Telekommunikation, Internet der Dinge, als auch Automobilindustrie[10] teils im produktiven Einsatz und fordern ein robustes und geeignetes Freigabemanagement.
  • Im Cloud Computing werden sog. Feeds genutzt, um Pakete zu bündeln und verteilen.[11]
  • Ein anderes Instrument sind Container, speziell Docker.
  • In den Wissenschaften, wo häufig mit Publikationen gearbeitet wird, kann ein sog. Peer-Review als eine Freigabe verstanden werden.
  • Die NASA bietet seine für die Raumfahrt entwickelte Software der Öffentlichkeit an und hat dafür ein eigenständiges Programm aufgelegt.[12]

Zusammenhang Informationstechnologie und ITIL

Das Freigabemanagement dient dem Service Management und ist Teil des IT-Service-Management (ITSM).[13] Es ist seit ITIL v3 eine eigenständige Prozesseinheit.

Im Zusammenhang mit ITIL stehen das geforderte Definitive Hardware Library und Definitive Software Library.[14] Die Bedeutung ist jeweils die Archivierung (logische Verwaltung) von technischen bzw. Softwarekomponenten eines Unternehmens. Das DSL wurde nach der Veröffentlichung von ITIL v3 zu DML (Definitive Media Library) umbenannt.

Normen

Literatur

Artikel

  • Pratik K. Biswas: Autonomic Software Release Management for Communications Networks. In: 2007 10th IFIP/IEEE International Symposium on Integrated Network Management. IEEE, Munich, Germany 2007, ISBN 978-1-4244-0798-9, S. 179–188, doi:10.1109/INM.2007.374782.
  • Murali Ramakrishnan: Software release management. In: Bell Labs Technical Journal. Band 9, Nr. 1, 11. Mai 2004, S. 205–210, doi:10.1002/bltj.20015 (englisch).

Modernere Lehrtexte

Klassische Werke

  • Michael E Bays: Software Release Methodology. Prentice Hall, Philadelphia, PA 1999 (englisch).
  • C. Michael Pilato, Ben Collins-Sussman, Brian W. Fitzpatrick, Kathrin Lichtenberg, C. Michael Pilato: Versionskontrolle mit Subversion: Software-Projekte intelligent koordinieren. 3. Aufl., komplett überarb. und aktualisiert. O’Reilly, Beijing Köln 2009, ISBN 978-3-89721-897-0 (red-bean.com).
  • Tobias Wassermann: Versionsmanagement mit Subversion: Installation, Konfiguration, Administration ; [Repository-Verwaltung und -Administration, Serverkonfiguration von Apache und svnserve, grafische Oberflächen für Subversion, vollständige Befehlsreferenz] (= Programmierung). 1. Auflage. mitp, Heidelberg 2006, ISBN 978-3-8266-1662-4.

Siehe auch

Einzelnachweise

  1. ↑ Fabian Wolf: Fahrzeuginformatik: Eine Einführung in die Software- und Elektronikentwicklung aus der Praxis der Automobilindustrie. Springer Fachmedien Wiesbaden, Wiesbaden 2018, ISBN 978-3-658-21223-0, doi:10.1007/978-3-658-21224-7 (springer.com [abgerufen am 28. Juli 2022]).
  2. ↑ R.J. Cloutier (Editor in Chief): Deploying, Using, and Sustaining Systems to Solve Problems - SEBoK. In: The Guide to the Systems Engineering Body of Knowledge (SEBoK), v. 2.6. The Trustees of the Stevens Institute of Technology, 28. Juli 2022, abgerufen am 28. Juli 2022 (englisch).
  3. ↑ Dominic Müller, Joachim Herbst, Markus Hammori, Manfred Reichert: IT Support for Release Management Processes in the Automotive Industry. In: Business Process Management. Band 4102. Springer Berlin Heidelberg, Berlin, Heidelberg 2006, ISBN 978-3-540-38901-9, S. 368–377, doi:10.1007/11841760_26 (springer.com [abgerufen am 28. Juli 2022]).
  4. ↑ Kim H. Pries: Project management of complex and embedded systems : ensuring product integrity and program quality. CRC Press, Boca Raton 2009, ISBN 978-1-4200-7206-8, S. 215 ff. (englisch).
  5. ↑ a b Tyler Cipriani: How the Wikimedia Foundation deploys code. In: Diff. 7. Oktober 2021, abgerufen am 28. Juli 2022 (amerikanisches Englisch).
  6. ↑ Stefano Zacchiroli: Release management in Open Source projects. Abgerufen am 28. Juli 2022 (englisch).
  7. ↑ Federica Sarro: Release Management of Mobile Apps. Abgerufen am 28. Juli 2022 (englisch).
  8. ↑ Abhinav Krishna Kaiser: Release Management in DevOps. In: Reinventing ITIL® in the Age of DevOps. Apress, Berkeley, CA 2018, ISBN 978-1-4842-3975-9, S. 271–295, doi:10.1007/978-1-4842-3976-6_10 (springer.com [abgerufen am 28. Juli 2022]).
  9. ↑ Apache Subversion - Community Guide - Making Subversion Releases. Abgerufen am 28. Juli 2022.
  10. ↑ Wolfgang Rudschies: Updates over the air: Wie das Auto per Software aufgefrischt wird. In: ADAC. Allgemeiner Deutscher Automobil-Club e.V. (ADAC), 27. Juli 2021, abgerufen am 28. Juli 2022.
  11. ↑ ramiMSFT: What are feeds? - Azure Artifacts. Abgerufen am 28. Juli 2022 (amerikanisches Englisch).
  12. ↑ Home | NASA Software Catalog. Abgerufen am 28. Juli 2022.
  13. ↑ Stefan Kempter, Andrea Kempter: Release Management | IT Process Wiki. IT Process Maps GbR, abgerufen am 28. Juli 2022 (englisch).
  14. ↑ ITIL Definitive Software Library and Definitive Hardware Store. Abgerufen am 28. Juli 2022 (amerikanisches Englisch).
  15. ↑ 14:00-17:00: ISO/IEC 20000-1:2018. Abgerufen am 10. Februar 2021 (englisch).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Releasemanagement&oldid=224896514“