Checkliste Release Policy

Aus IT Process Wiki
Wechseln zu: Navigation, Suche

Checkliste Release Policy - Vorlage Release Policy


 

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

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

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

 

Überblick

Checkliste Release Policy

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)

 

[ Infobox ]

Link zu dieser Seite:
Sprachversionen: Deutsch | English
Abbildung: Release Policy (.JPG)
Autor: , IT Process Maps