Ausarbeitung ITIL Release Management

Aktuelle Themen der Informatik
IT Infrastructure Library
Release Management
Oliver Schmid
AI 8
Inhalt
I
iii
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 ITOrganisation. 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 ReleasePolicies, 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
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
6
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
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.
8
9
Release Management Prozess
Den Ablauf des Release Management kann durch folgendes WorkflowDiagramm 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
4
10
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.