Release Management. Aktuelle Themen der Informatik. Oliver Schmid

Transkript

1 Release Management Aktuelle Themen der Informatik Oliver Schmid Agenda Einführung Begriffsbestimmungen Release Identifikation Release Typen Release Management Prozess Release Richtlinien Release Planung Build Management Testing Back-Out Planung Rollout Planung Kommunikation und Schulung Nutzen und Mögliche Probleme Verbindung zu anderen Prozessen Kosten 2 1

2 Was heißt Release? Sammlung von autorisierten Änderungen an einem IT-Service oder an Teilen der IT-Infrastruktur Release besteht typischerweise aus einer Anzahl an Problem fixes und Erweiterungen 3 Release Einteilung Major Releases Minor Releases Emergency Releases 4 2

3 Ziele des Release Managements Planung und Überwachen des erfolgreichen Rolloutsvon Soft- und Hardwarekomponenten Entwurf und Implementierung von standardisierten Verfahren zur Implementation von IT-Services Sicherstellung, dass ausschließlich autorisierte und getestete Versionen von Soft- und Hardware eingesetzt werden Sicherstellung, dass Originale jeder SW sicher in DSL und dass CMDB aktuell ist. Kommunikation und Management der Kundenerwartungen während der Planung und des Rollouts neuer Releases 5 Wann sollte Release Management verwendet werden? Bei großen oder kritischen Hardware- Rollouts Bei größeren Software-Rollouts Bei Bündelung eines Satzes von Änderungen in Managebare Einheiten 6 3

4 Definitive Software Library (DSL) -1- Sicherer Verbund in der die endgültigen und autorisierten Versionen aller SW CIs gespeichert und geschützt sind Enthält Masterkopien jeder SW und der Dokumentationen eines Systems in einer Organisation Die Konfiguration der DSL, welche für das Release Management benötigt wird, sollte vor Entwicklungsbeginn definiert werden DSL ist ein Teil der Release Richtlinien 7 Definitive Software Library (DSL) -2- Die Definition enthält: Ort der DSL, HW und SW die benutzt wird Namenskonventionen Umgebungen die unterstützt werden Inhalt der DSL (z.b. Quellcode, Objekt-Code kontrollierter Builds und zugehöriger Dokumentation, ) Wie lange alte Releases zurückgehalten werden Prüfprozeduren Kapazitätspläne für DSL Prozeduren die Sicherstellen das DSL vor fehlerhaften und unautorisierten Änderungen geschützt ist Sicherheitsvorkehrungen für die Einreichung von Änderungen und das Herausgeben von SW (BackUp - und Recovery-Prozeduren) 8 4

5 Definitive Hardware Store (DHS) Bereich für die sichere Aufbewahrung der übrigen HW Details dieser Komponenten, ihre jeweiligen Versionen und Inhalte sollten umfassend in der CMDB abgelegt sein 9 Configuration Management Database (CMDB) Synchronisation zwischen CMDB und DSL Zur Unterstützung des RM-Prozesses sollte sie folgende Informationen enthalten: Definitionen der geplanten Releases Aufzeichnungen der betroffenen CIs, geplanter und vergangener Releases Informationen der von den Release Komponenten betroffener Bereiche 10 5

6 DSL und CMDB 11 Release Unit Beschreibt einen Teil der IT-Infrastruktur, welcher released wird Ziel ist die Entscheidung eines passenden Releas-Unit Levels für jede SW oder für jeden SW-Typ Dabei helfen folgende Faktoren: Anzahl der Änderungen in jedem Level Anzahl der Ressourcen, Zeit für Build, Test, Vertrieb und Implementierung des Releases Schwierigkeitsgrad der Implementierung Komplexität der Schnittstellen zwischen vorgeschlagener Unit und dem Rest der IT-Infrastruktur Verfügbarer Festplattenplatz in der Build-, Test-, Vertriebs- und Produktionsumgebung 12 6

7 Release Identifikation Releases sollten eindeutig identifiziert werden können Release Identifikation sollte einen Verweis zum zugehörigen CI enthalten Versionsnummer: Major Releases: Payroll_System v1, v2, v3, Minor Releases: Payroll_System v1.1, v1.2, v1.3, Emergency fix Releases: Payroll_System v1.1.1, v1.1.2, v1.1.3, 13 Release Typen -1- Full Release Alle Komponenten der Release Unit werden werden zusammen gebaut, getestet, vertrieben und implementiert Es werden auch CIs getestet die nicht geändert wurden Größerer Zeitaufwand Regression Testing Ersetzt vorhandene Releases 14 7

8 Release Typen -2- Delta Release Enthält nur die CIs welche geändert wurden oder neu hinzugekommen sind Falls ein Full Release nicht gerechtfertigt werden kann Muss von Fall zu Fall entschieden werden CAB gibt Empfehlung, anhand aller relevanten Fakten, ob die vorgeschriebene Release Unit passend ist 15 Release Typen -3- Package Release Um längere Perioden der Stabilität zu gewährleisten und gleichzeitig die Anzahl der Releases zu reduzieren Besteht aus zusammenhängenden CIs, die gemeinsam implementiert werden Kann Full und Delta Releases enthalten 16 8

9 Release Management Prozess Festlegen von Richtlinien und Planung der Releases Design, Aufbau und Zusammenstellung des Releases Test und Abnahme des Releases Implementationsplanung Vorbereitung der Mitarbeiter Rollout 17 Release Management Prozess 18 9

10 Release Richtlinien -1- Release Manager definiert Richtlinien für die Zusammensetzung und Bereitstellung des Releases Klärung der Rollen und der Verantwortungen der am Release beteiligten Personen Sind üblicherweise ein Teil des Change Management Plans 19 Release Richtlinien -2- Release Richtlinien sollten enthalten: Release-Nummerierung/Namensgebung Release Häufigkeit Welcher Level in der IT-Infrastruktur, von Releases kontrolliert wird (z.b. Komplette Systeme oder einzelne Dateien) Definition der Major oder Minor Releases Anleitung wie und wann Releases dokumentiert werden sollen Voraussichtliche Auslieferungen für jeden Release-Typ Richtlinien für die Produktion und der Grad des Testens des Back-Out Plans Beschreibung des Release Management Kontrollprozesses Dokumentation für die exakte Konfiguration der DSL 20 10

11 Release Planung Konsens über Release Inhalt High-Level Release Zeitplan erstellen Untersuchung und Bewertung der vorhandenen SW und HW Einigung über Rollen und Verantwortlichkeiten Verhandeln mit HW und SW Lieferanten Erstellen eines Back-Out Plans Entwickeln eines Qualitätplans für den Release Planung der Zustimmung des Supports und der Kunden 21 Input für Release Planung Project Life-Cycle Autorisierte RFCs Release Richtlinien Übersicht über Kunden-Wünsche Einschränkungen und Abhängigkeiten CAB output 22 11

12 Build Management SW und HW Komponenten sollten kontrolliert implementiert werden, um den Prozess reproduzierbar zu machen Bei SW wird aus dem neuen Quellcode der Entwickler ausführbare Versionen gebaut Automatisierte Build Prozess 23 Testing Bevor ein Release an die Produktionsumgebung gegeben werden kann, sollte er strengen Tests und der Benutzerakzeptanz unterzogen werden Folgende Testarten sollten verwendet werden: Funktionale Tests Betriebs Tests Performanz Tests Integrations Tests Ungenügendes Testen ist der häufigste Grund für Fehler in den Änderungen und Releases 24 12

13 Back-Out Planung Dokumentieren der Aktionen, um einen Service, teilweise oder komplett, wiederherzustellen Ist zwar Aufgabe des Change Managements, aber RM muss sicherstellen das die Back-Out Pläne für jede Änderung innerhalb eines Releases zusammenarbeiten Release Back-Out Plan 25 Rollout Planung Erweitert den Release Plan um Details für den Installationsprozess und den vereinbarten Implementationsplan Erstellen eines detaillierten Zeitplans Auflistung der zu installierenden CIs Erstellen der Release Notes Kommunikationsplanung Entwickeln von Bestellplänen Planen von Meetings mit Managern und allen Gruppen die am Release beteiligt sind 26 13

14 Kommunikation und Schulung Kunden und Support Mitarbeiter müssen wissen was geplant ist und wie es sie beeinflusst Dies wird normalerweise durch Training sessions und parallelem Arbeiten erreicht Probleme und Änderungen die während der Roll-Out Phase auftreten sollten allen Beteiligten kommuniziert werden Alle Einschränkungen für den Endanwender müssen kommuniziert werden 27 Verteilung und Installation -1- Veteilung von SW Releases von der Build- in die Test- und dann in die Produktions- Umgebung sollte vollendet werden mit allen zugehörigen HW Änderungen Prozess für die Beschaffung, Speicherung, Versendung, Quittierung und Verfügbarkeit von Gütern soll sicherstellen, dass die Geräte an ihrem Ziel ankommen 28 14

15 Verteilung und Installation -2- Automatische Verteilung von SW an entfernte Standorte spart Zeit und Geld Testen der Installationsroutinen Um einen reibungslosen Roll-Out sicherzustellen, sollte man eine automatisierte Überprüfung auf der Zielplattform durchführen CMDB sollte aktualisiert werden, damit sie die Endlage widerspiegelt Akzeptanztest bei Endverbraucher durchführen Nach einer erfolgreichen Installation sollten die Configuration Management Datensätze aktualisiert werden 29 Nutzen Erhöhte Qualität der Services Konsistenz innerhalb der Release Prozesse Minimierung der Störungen eines Services Stabile Test- und Einsatzumgebung, da Änderungen in Releases zusammengefasst werden Einfacheres begründen der Kosten für Regression Testing Minimierung der Anforderungen für Regression-Testing, bedeutet größere Testabdeckung Fehlerreduzierung durch kontrollierten Release von HW und SW Einsparen von Support Kosten (durch aufrechterhalten stabiler SW an vielen Orten) Reduzierung der Wahrscheinlichkeit von illegalen Kopien Reduziert Zeit bis zum Release Reibungsloser Übergang von Releases aus den Entwicklungsaktivitäten zum Kunden 30 15

16 Mögliche Probleme Widerstand von Mitarbeitern Erfahrung zeigt das die Teams, welche am meisten von RM profitieren würden keine Zeit haben dies einzuführen Es wird versucht die RM Prozeduren zu umgehen Mitarbeiter kommen in Versuchung die Installationsprozeduren eines Emergency Fixes zu umgehen Manche sehen das RM als hinderlich und zu kostspielig an Unklare Verantwortlichkeiten zwischen Operationalen- und Entwicklungsteam Ungenügende Ressourcen für angemessenes Testen, reduziert die Effektivität dieser Prozeduren Zuwenig Rechnerpower oder Netzwerkressourcen machen es unmöglich einen neuen Release zu bauen oder zu testen Tests auf einer Plattform können ausreichen, aber es können Fehler in anderen Plattformen auftreten 31 Verbindung zu anderen Prozessen -1- Configuration Management Wenn neue SW in DSL, sollten Details dazu, gleichzeitig in CMDB eingefügt werden CMDB sollte auch immer den aktuellen Status jeder autorisierter SW und HW enthalten Release Management kann auch verschiedene Services des CMs verwenden 32 16

17 Verbindung zu anderen Prozessen -2- Change Management Release Manager, Mitglied im CAB, gibt Ratschläge über den Inhalt und die Zeitpläne der Releases Release Management überblickt die Details eines Roll-Outs einer Änderung, untersteht aber der Kontrolle und Autorität des Change Managements 33 Verbindung zu anderen Prozessen -3- Problem Management und Service Desk Nach einer erfolgreichen Verteilung und Installation eines Releases, müssen einige Datensätze des Problem Management Systems aktualisiert werden: Alle verwandten Problem- und Erweiterungs- Requests schließen Alle neuen Probleme, sollten in die DB eingefügt werden, damit die Service Desk Mitarbeiter den neuen Release unterstützen können 34 17

18 Kosten des Release Managements Entwicklung neuer Methoden für Release und Rollout Management Ausbildung betreffend RM Richtlinien, Methoden und Tools Mitarbeiter Kosten für Entwicklung und Ausführung der Methoden und Tools Speicherkosten für DSL Kosten für Build, Tests, Verteilung und Archivierung (SW, HW) Kosten für übriges Equipment Kosten für Computer und Netzwerkressourcen Kosten für Installation und Management des Vertriebs 35 Fragen? 18