Checkliste Release Policy: Unterschied zwischen den Versionen

Aus IT Process Wiki
(Die Seite wurde neu angelegt: „<seo metakeywords="release policy, release policy itil, itil release policy, release richtlinie" metadescription="Die Release Policy ist ein Satz von Regeln f…“)
 
Zeile 28: Zeile 28:
<p>&nbsp;</p>
<p>&nbsp;</p>


===== Konventionen zur Release-Identifikation, -Nummerierung und -Bezeichnung =====
===== Konventionen zur Release-Identifikation =====
(Konventionen zur Release-Identifikation, -Nummerierung und -Bezeichnung)


===== Anforderungen =====
===== Anforderungen =====
Zeile 40: Zeile 41:
# Ansatz und Richtlinien für das Gruppieren von [[Change Management#ITIL Change|Changes]] in [[Release und Deployment Management#Release|Releases]]
# Ansatz und Richtlinien für das Gruppieren von [[Change Management#ITIL Change|Changes]] in [[Release und Deployment Management#Release|Releases]]
# Planungs- und Dokumentationsanforderungen, z.B.
# Planungs- und Dokumentationsanforderungen, z.B.
## Beim Deployment eines Minor Releases wird der einfachere Minor-Change-Deployment-Prozess ("[[Change Management#ITIL Minor Changes|Implementierung von Minor Changes]] verwendet und in [[Release und Deployment Management#Release Record|Release Records]] und [[Change Management#Change Record|Change Records]] dokumentiert
## Beim Deployment eines Minor Releases wird der einfachere Minor-Change-Deployment-Prozess ("[[Change Management#ITIL Minor Changes|Implementierung von Minor Changes]]") verwendet und in [[Release und Deployment Management#Release Record|Release Records]] und [[Change Management#Change Record|Change Records]] dokumentiert
## Beim Deployment eines Major Releases ist ein formelles Projekt mit vollständiger Dokumentation erforderlich
## Beim Deployment eines Major Releases ist ein formelles Projekt mit vollständiger Dokumentation erforderlich
## Das Deployment eines Notfall-Releases erfordert die Genehmigung durch das [[Rollen in ITIL V3#Emergency Change Advisory Board (ECAB)|ECAB]]. Es wird von einem [[Rollen in ITIL V3#Major Incident Team |Major Incident Team]] geplant, koordiniert und dokumentiert
## Das Deployment eines Notfall-Releases erfordert die Genehmigung durch das [[Rollen in ITIL V3#Emergency Change Advisory Board (ECAB)|ECAB]]. Es wird von einem [[Rollen in ITIL V3#Major Incident Team |Major Incident Team]] geplant, koordiniert und dokumentiert

Version vom 15. September 2012, 16:09 Uhr

<seo metakeywords="release policy, release policy itil, itil release policy, release richtlinie" metadescription="Die Release Policy ist ein Satz von Regeln für die Überführung unterschiedlicher Arten von Releases in die Life-Betriebsumgebung, ..." />

Checkliste Release Policy - Vorlage Release Policy
Checkliste Release Policy - Vorlage Release Policy


Überblick

ITIL-Prozess: ITIL 2011 Service Transition - Release und Deployment Management

Checklisten-Kategorie: Checklisten ITIL Service Transition (Serviceüberführung)

Quelle: Checkliste "Release Policy/ Release-Richtlinie" aus der ITIL-Prozesslandkarte

 

Die Release Policy (Release-Richtlinie) enthält einen Satz von Regeln für die Überführung unterschiedlicher Arten von Releases in die Life-Betriebsumgebung, wobei je nach Dringlichkeit und Auswirkung unterschiedliche Vorgehensweisen für die Releases festgelegt werden.

 

ITIL Release Policy - Inhalte

Die Release Policy (Release-Richtlinie) umfasst in der Regel die folgenden Informationen:

 

Konventionen zur Release-Identifikation

(Konventionen zur Release-Identifikation, -Nummerierung und -Bezeichnung)

Anforderungen

(Anforderung, dass nur Software aus der DML in Releases eingehen darf)

Release-Level

Für jeden Release-Level, z.B. Major, Minor oder Notfall-Release:

  1. Bezeichnung des Release-Levels
  2. Erwartete Häufigkeit solcher Releases
  3. Rollen und Verantwortlichkeiten sowie Eingangs- und Ausgangskriterien für die unterschiedlichen Phasen des Release- und Deployment-Management-Prozesses (diese können für spezifische Serviceüberführungen je nach Notwendigkeit angepasst werden)
  4. Ansatz und Richtlinien für das Gruppieren von Changes in Releases
  5. Planungs- und Dokumentationsanforderungen, z.B.
    1. Beim Deployment eines Minor Releases wird der einfachere Minor-Change-Deployment-Prozess ("Implementierung von Minor Changes") verwendet und in Release Records und Change Records dokumentiert
    2. Beim Deployment eines Major Releases ist ein formelles Projekt mit vollständiger Dokumentation erforderlich
    3. Das Deployment eines Notfall-Releases erfordert die Genehmigung durch das ECAB. Es wird von einem Major Incident Team geplant, koordiniert und dokumentiert
Leitlinien für verschiedene Ansätze beim Release Deployment

Welches sind die spezifischen Bedingungen, die einen bestimmten Ansatz zur bevorzugten Option machen, z.B.

  1. "Big-bang" versus stufenweises Deployment
  2. "Push"- versus "Pull"-Deployment
  3. Systemgesteuertes versus manuelles Deployment
Einschränkungen für das Release Deployment

Service Level und Operational Level Agreements definieren typischerweise Verfügbarkeits-Ziele, einschließlich erlaubter Wartungsfenster, die ggf. zur Nicht-Verfügbarkeit des Services führen. Sofern keine Notfall-Releases erforderlich sind, werden Releases in der Regel während dieser Wartungsfenster ausgerollt. Release Management muss demzufolge diese Service-spezifischen Einschränkungen in Einschränkungen für das Ausrollen von Releases für Systeme, Anwendungen und andere Komponenten übersetzen, die für die Verfügbarkeit des Services erforderlich sind.

  1. Service-spezifische Einschränkungen für das Release Deployment wie in den Service Level und Operational Level Agreements definiert
    1. Service A
      1. Erlaubte Häufigkeit neuer Releases nach Release-Typ
      2. Release-Zeitfenster und Einschränkungen (z.B. Samstag 01.00 – 04.00 Uhr, nicht im Dezember)
    2. Service B
  2. Einschränkungen für das Ausrollen von Releases für Systeme, Anwendungen und andere Komponenten, die obige Services unterstützen
    1. System A
      1. Erlaubte Häufigkeit neuer Releases nach Release-Typ
      2. Release-Zeitfenster und Einschränkungen (z.B. Samstag 01.00 – 04.00 Uhr, nicht im Dezember)
    2. System B
Bevorzugte Mechanismen

(Bevorzugte Mechanismen für automatisierte Release Deployments)