Aktuelle Themen der Informatik IT Infrastructure Library Release Management Oliver Schmid AI 8
Inhalt iii I Inhalt I Inhalt...iii II Abbildungsverzeichnis...iv 1 Einführung...1 2 Release Begriffe...2 2.1. Release Einteilung...2 2.2. Release Einheit...2 2.3. Release Identifikation...3 2.4. Release Typen...3 2.5. Definitive Software Library (DSL)...4 2.6. Definitive Hardware Store (DHS)...5 2.7. Configuration Management Database (CMDB)...5 3 Release Management Prozess...6 3.1. Aktivitäten...6 3.2. Prozess...8 4 Zusammenhang mit anderen Prozessen... 10 5 Zusammenfassung...11
iv Abbildungsverzeichnis II Abbildungsverzeichnis Abbildung 1: Interaktion zwischen DSL und CMDB...5 Abbildung 2: Releasestrategie...6 Abbildung 3: Prozess des Release Managements...8 Abbildung 4: Ablauf des Release Management...9
1 Einführung 1 Einführung Wo die Häufigkeit und Komplexität von Änderungen an konkreten Komponenten zunimmt, ist Release Management der Effizienz- und Qualitäts-Hebel für die IT- Organisation. Der Prozess stellt die Bündelung von Changes und deren ordnungsgemäße Realisierung in der Infrastruktur sicher. Er erstreckt sich von der Releaseplanung, über die Steuerung der Test- und Abnahmeverfahren bis hin zur Backout- und Roll-out-Planung auf organisatorischer und technischer Ebene. Er ist mit dem Anforderungsmanagement verknüpft, definiert die Release- Policies, steuert die Schnittstellen für Softwarelieferungen, autorisiert Releases für den Einsatz und archiviert die Masterkopien und Referenzkonfigurationen und löst den Change-Prozeß für den Roll-out aus.
Release Begriffe 2 2 Release Begriffe Der Ausdruck Release wird verwendet um eine Sammlung an autorisierten Änderungen an einem IT Service oder an Teilen der IT-Infrastruktur zu beschreiben. Ein Release wird anhand der beinhalteten Request for Changes definiert. Er besteht typischerweise aus einer Anzahl von Problembehebungen und Erweiterungen eines Services. 2.1. Release Einteilung Releases werden typischerweise unterteilt in: Major Release: Enthält größere Bereiche an neuer Funktionalität, welche zum Teil die Behebung von Problemen überflüssig machen. Solche Releases ersetzen alle vorhergehenden Minor Releases und Emergency Fixes. Minor Release: Enthält kleinere Erweiterungen und Fixes, welche möglicherweise schon bei einem Emergency Fix ausgegeben wurden. Emergency Fix: Enthält die Behebung einer kleinen Anzahl an bekannten Problemen. 2.2. Release Einheit Eine Release-Einheit beschreibt an der Anteil an der Infrastruktur, der zusammenhängend autorisiert wird. Diese Einheiten werden in der Regel gekennzeichnet durch die Umgebung, für die sie Gültigkeit besitzen (z.b. Entwicklungsumgebung, Testumgebung, Produktivumgebung, Archiv).
3 Release Begriffe 2.3. Release Identifikation Häufig werden innerhalb einer Umgebung mehrere Versionen des gleichen Release eingesetzt. Aus diesem Grunde ist es notwendig, diese durch Versionsoder Buildnummern eindeutig zu kennzeichnen. Die Release Identifikation sollte eine Referenz zu dem Configuration Item enthalten, welcher durch den Release repräsentiert wird, und eine Versionsnummer die häufig aus 2 oder 3 Teilen besteht. Beispiel für Release-Namen sind die folgenden: Major Releases: Payroll_System v.1, v.2, v.3, Minor Releases: Payroll_System v.1.1, v.1.2, v.1.3, Emergency Fix: Payroll_System v.1.1.1, v.1.1.2, v.1.1.3, 2.4. Release Typen Es werden Delta-Release, Package-Release und Full Release unterschieden. Full-Release: Der wichtigste Vorteil eines vollen Releases besteht darin, dass alle Komponenten der Release-Einheit zusammen implementiert, gebaut, getestet und vertrieben werden. Dadurch werden auch diejenigen CI s getestet die nicht geändert wurden. Der Nachteil eines solchen Releases ist der erhöhte Zeitaufwand und der Anstieg der Hardware Ressourcen. Delta-Release: Dieser Release enthält nur die CI s welche geändert wurden oder neu hinzugekommen sind. Er wird dann verwendet wenn ein Full Release nicht gerechtfertigt werden kann, dies sollte aber immer von Fall zu Fall entschieden werden. Hierzu gibt das CAB (Change Advisory Board), anhand aller relevanten Fakten, eine Empfehlung ob die vorgeschriebene Release Einheit passend ist.
Release Begriffe 4 Package Release: Wird verwendet um längere Perioden der Stabilität zu gewährleisten und um gleichzeitig die Anzahl der Releases zu reduzieren. Er besteht aus zusammenhängenden CI s, welche gemeinsam implementiert werden. Zum Beispiel, wenn Änderungen an einem System gleichzeitig Änderungen an einem anderem System erfordern. Ein Package Release kann Full und Delta Releases enthalten. 2.5. Definitive Software Library (DSL) Die Definitive Software Library ist ein Sicherer Verbund in der die endgültigen und autorisierten Versionen aller Software CI s gespeichert und geschützt sind. Sie enthält Masterkopien jeder Software und der Dokumentationen eines Systems in einer Organisation. Eine exakte Konfiguration der DSL, welche für das Release Management benötigt wird, sollte vor Entwicklungsbeginn definiert werden. Darüber hinaus ist die DSL ein Teil der Release Richtlinien oder des Change und Configuration Management Plans der Organisation. Die Definition der DSL sollte folgendes enthalten: o Ort der DSL, Hardware und Software die benutzt wird o Namenskonventionen o Umgebungen die unterstützt werden o Inhalt der DSL (z.b. Quellcode, Objekt-Code kontrollierter Builds und zugehöriger Dokumentation, ) o Wie lange alte Releases zurückgehalten werden sollen o Prüfprozeduren o Kapazitätspläne für DSL o Prozeduren die Sicherstellen das DSL vor fehlerhaften und unautorisierten Änderungen geschützt ist o Sicherheitsvorkehrungen für die Einreichung von Änderungen und das Herausgeben von Software (BackUp - und Recovery - Prozeduren)
5 Release Begriffe 2.6. Definitive Hardware Store (DHS) Der Definitive Hardware Store ist ein sicherer Bereich für die Aufbewahrung der übrigen Hardware. Details dieser Komponenten, ihre jeweiligen Versionen und Inhalte sollten umfassend in der Configuration Management Database abgelegt sein. 2.7. Configuration Management Database (CMDB) Die CMDB wird während des Release Management Prozesses, gleichzeitig mit den Updates an der DSL, aktualisiert. Um den Release Management Prozess zu unterstützen sollte sie folgende Informationen enthalten: o Definitionen der geplanten Releases o Aufzeichnungen der betroffenen CIs, geplanter und vergangener Releases o Informationen der von den Release Komponenten betroffener Bereiche Folgende Abbildung zeigt die Interaktion zwischen der DSL und der CMDB. Abbildung 1: Interaktion zwischen DSL und CMDB
Release Management Prozess 6 3 Release Management Prozess Der Release Management Prozess besteht aus folgenden Aktivitäten, die sicherstellen, dass ein Release von der Entwicklungsumgebung über die Testumgebung in die Produktionsumgebung überführt werden kann. 3.1. Aktivitäten Das Release Management bezieht sich auf Änderungen an Hardware, Software sowie an Installationsanweisungen, Dokumentationen, Benutzerhandbüchern. Eine grafische Darstellung für die Releasestrategie siehe bitte Abbildung 2. Abbildung 2: Releasestrategie 1. Festlegen einer Release Strategie Die strategische Vorgehensweise wird im Rahmen des Change Management festgelegt, abhängig von Größe und Art der Systeme, Anzahl und Häufigkeit der erforderlichen Änderungen sowie spezifischen Anforderungen der Anwender. 2. Planen der Releases Die Release Planung umfasst: o Definieren des Release Inhalts o Abstimmen der Rollen und Verantwortungen
7 Release Management Prozess o Abstimmen der Phasen(Zeiten, Standorte, Geschäftsbereiche und Kunden) o Erstellen eines Release Zeitplans o Planen des Ressourceneinsatzes o Erstellen der Sicherungspläne(Back-out) o Entwickeln des Qualitätsplans für die Releases 3. Dokumentieren und sichern der Releases Das Release Management arbeitet eng mit den Prozessen Change Management und Configuration Management zusammen, um sicherzustellen, dass die gemeinsam genutzte CMDB up-to-date gehalten wird. 4. Abnehmen der Releases Bevor ein Release in die produktive Umgebung übergeben wird, muss er eingehenden Tests unterzogen werden. Dies umfasst funktionelle, operationelle, Leistungs- und Integrationstests. Das Change Management stellt sicher, dass eine formelle Freigabe durch die Anwender vorliegt. 5. Überwachen der Release Auslieferung Gleichgültig welche Art das Release ist, sollten folgende Richtlinien eingehalten werden: o Ausschließlich die in der DSL gespeicherte Version verwenden. o Alle Releases durch das Change Management genehmigen lassen. o Alle Aktionen in der CMDB sofort nachführen. o Jeweils eine neue Versionsnummer vergeben. o Die Anwender so früh wie möglich über die bevorstehenden Änderungen informieren. o Die Änderungen in der Dokumentation so schell wie möglich nachführen. o Erfolg und Vollzug an das Change Management rückmelden.
Release Management Prozess 8 3.2. Prozess Abbildung 3: Prozess des Release Managements In der Abbildung 3 ist es leicht zu sehen, dass die Umgebung in drei Teile aufgeteilt ist, nämlich Entwicklungsumgebung, Testumgebung und Produktionsumgebung. In jeder Teilumgebung laufen bestimmte Aktivitäten. Sie kommunizieren mit DSL, DHS und CMDB, dann holen sie die Informationen, die sie brauchen. Die durch das Release Management erstellten Information, wie RFCs, Dokumentation und etc. werden in solche Datenbanken nachgeführt, so dass die Datenbanken immer up-to-date eingehalten werden.
9 Release Management Prozess Den Ablauf des Release Management kann durch folgendes Workflow- Diagramm beschrieben werden: Abbildung 4: Ablauf des Release Management Vor der Release Planung wird zuerst eine Strategie für das Release bestimmt. In der Planungsphase werden dann die Inhalte des Release, die genauen Schritte, der Zeitplan etc. festgestellt und es kommt danach zur Testphase. Hier wird die Planung getestet. Wenn irgendwelche Probleme auftauchen, muss sie noch mal verbessert werden, bis ein problemloses Release rauskommt. Bei der Release Auslieferung muss das Release Management überwachen, ob es erfolgreich durchgeführt wird. Zu beachten ist, dass in jeder Phase des Release Management alle entsprechenden Informationen rechtzeitig in die CMDB eingeschrieben werden müssen.
Zusammenhang mit anderen Prozessen 10 4 Zusammenhang mit anderen Prozessen Das Change Management hat mit allen Prozessen nach ITIL einen Zusammenhang. Das Change Management erhält die RFCs aus anderen Prozessen und die RFCs werden erfasst, klassifiziert und schließlich evaluiert, die dadurch erstellten Information werden in die CMDB eingeschrieben. 1. Configuration Management Das Change Management und Release Management haben einen engen Zusammenhang mit dem Configuration Management. Die beiden Management Prozesse holen die RFCs und anderen Informationen aus der CMDB, die von dem Configuration Management gepflegt ist, und führen sie in die CMDB rechtzeitig nach, so dass sich die CMDB immer im aktuellen Zustand befindet. 2. Incident und Problem Management Wenn man das Incident Management, Problem Management und Change Management betrachtet, muss man die Unterschiede dazwischen beachten. An Incident is not a Change and a Problem may not led to a Change. 3. Service Desk Es ist einerseits empfehlungswert, dass der Service Desk regelmäßig ein Review über das Change Management durchführt, um effizient arbeiten zu können. Sobald ein Change Management Prozess durchgeführt worden ist, muss der Service Desk ein Review machen, um zu bestimmen, ob der Prozess wie geplant läuft. Wenn Probleme auftauchen, muss der Service Desk das Change Management sofort informieren. Andererseits ist es notwendig, den Service Desk und das Problem Management rechtzeitig zu informieren, wenn ein neues Release veröffentlicht wird. Danach können der Service Desk und das Problem Management Supports anbieten und Fehler sammeln.
11 Zusammenfassung 5 Zusammenfassung Die Zielsetzung des Release Managements ist die Planung und der Überblick von Hard- und Software-Rollouts. Dabei müssen bestehende CIs geschützt werden und es muss sichergestellt sein, dass ausschließlich autorisierte und getestete CIs in der Produktivumgebung eingesetzt werden. Das Release Management ist daher für die Betreuung und Kontrolle von DSL und DHS verantwortlich, in denen eine logische und physische Speicherung bzw. Aufbewahrung der verwendeten CIs stattfindet. Die Erstellung und das Management von Releases gehört ebenfalls zu den Aufgaben des Release Managements. Releases werden dabei in Full-, Delta- und Package-Releases unterschieden. Der Release Management Prozess ist für die operationale Definition und Implementation der Releases zuständig. Das Change Management übt dabei die Kontrolle aus. Der Kunde profitiert von einem geordneten Release Management durch die standortübergreifende konsistente Software und die Einhaltung von Unternehmensstandards. Damit ist eine hohe Qualität der eingesetzten Software gewährleistet, so dass Fehler minimiert werden können und in späteren Releases vollständig beseitigt werden. Gleichzeitig sorgt das Release Management dafür, dass nur autorisierte Software eingesetzt wird. Somit ist sichergestellt, dass Gefahren durch Viren oder illegale Software-Lizenzen reduziert werden. Durch geeignete Notfallplanung ist es möglich, im Falle von Störungen auf eine etablierte Basis (Baseline) zurückzugreifen, um Service-Levels aufrechtzuerhalten.