OIM Release Management

Dieses Dokument beschreibt einen One Identity Manager spezifischen Release-Prozess fuer Projekt-, Change- und Managed-Service-Arbeit. Ziel ist ein reproduzierbarer Ablauf von Anforderung bis Produktionsuebergabe mit klaren Verantwortlichkeiten, Pruefpunkten und Templates.

Zielbild

Ein OIM-Release ist erst releasefaehig, wenn fachlicher Scope, technische Aenderungen, Transportpakete, Tests, Rollback, Betriebsuebergabe und Freigaben nachvollziehbar dokumentiert sind.

Release-Arten

Release-Art	Einsatzfall	Fuehrung
Standard Release	Geplante Funktions- oder Prozessanpassungen	Release Manager
Hotfix	Fehlerkorrektur mit engem Scope und erhoehtem Zeitdruck	OIM Technical Lead
Emergency Change	Produktionsstoerung oder Sicherheitsrisiko mit unmittelbarem Handlungsbedarf	Change Manager
Platform Release	OIM Version, Service Pack, DB-/Infrastrukturkomponente	Release Manager und Infrastructure Lead

OIM-spezifischer Scope

Ein Release kann unter anderem folgende OIM-Bausteine enthalten:

Konfigurationen in Designer, Manager oder Web Portal.
Skripte, Templates, Prozesse, Prozessschritte und Prozesskomponenten.
Synchronisationsprojekte, Mappings, Workflows und Startkonfigurationen.
Rollenmodell, Berechtigungen, Attestation, Rezertifizierung und Genehmigungsworkflows.
Schemaerweiterungen, Customizer, Tabellenlogik und DB-nahe Anpassungen.
Reports, API-/Service-Integrationen, Job Service Konfiguration und Web-Anwendungen.
Betriebsartefakte wie Monitoring-Regeln, Runbooks, Scheduler und Service-Parameter.

Best Practices

Keine manuelle produktive Anpassung ohne dokumentierten Change, getesteten Transport und nachvollziehbare Freigabe.
Entwicklung, Test und Produktion muessen dieselbe Release-Reihenfolge einhalten: Dev, Test, PreProd falls vorhanden, Prod.
Transportpakete werden versioniert, mit Release-Manifest abgelegt und nur aus einer kontrollierten Quelle importiert.
Jeder Release-Kandidat enthaelt eine Liste betroffener OIM-Objekte, Abhaengigkeiten, Datenmigrationen und Betriebsfolgen.
Kritische OIM-Prozesse brauchen technische Tests fuer Job Queue, DBQueue, Synchronisation, Provisioning, Web/API und Berechtigungswirkung.
Rollback wird vor dem Go-Live geplant. Bei OIM sind Datenbank-Backup, Wiederherstellungsfenster und getestete Rueckfalloptionen zentral, weil reine Ruecktransporte nicht alle Daten- und Prozessfolgen sauber zurueckdrehen.
Anpassungen nutzen konsistente Namensraeume, zum Beispiel kundenspezifische Prefixe fuer Skripte, Prozesse und Tabellen.
Release Notes muessen fachlich lesbar und technisch verwertbar sein.
Nach jedem produktiven Import werden Queue, Job Services, Synchronisationslaeufe, Web-Anwendungen und relevante Logs aktiv ueberwacht.

Prozessuebersicht

flowchart TD
    A["Anforderung erfassen"] --> B["Release-Art und Prioritaet klassifizieren"]
    B --> C["Impact-Analyse fuer OIM-Objekte, Daten und Betrieb"]
    C --> D["Scope und Akzeptanzkriterien festlegen"]
    D --> E["Implementierung in Dev"]
    E --> F["Transportpaket und Release-Manifest erstellen"]
    F --> G["Import in Testumgebung"]
    G --> H["Technische Tests und Smoke Tests"]
    H --> I{"Test bestanden?"}
    I -- "Nein" --> E
    I -- "Ja" --> J["UAT und fachliche Abnahme"]
    J --> K{"Freigabe erteilt?"}
    K -- "Nein" --> D
    K -- "Ja" --> L["CAB, Go-Live-Plan und Rollback finalisieren"]
    L --> M["Deployment in Produktion"]
    M --> N["Post-Deployment Smoke Test"]
    N --> O{"Produktionscheck bestanden?"}
    O -- "Nein" --> P["Rollback oder Fix-forward nach Entscheidung"]
    O -- "Ja" --> Q["Hypercare und Betriebsuebergabe"]
    P --> Q
    Q --> R["Release abschliessen und Lessons Learned dokumentieren"]

Prozessdetails

1. Anforderung und Klassifizierung

Release Requirement mit Owner, Nutzen, Risiko, Terminwunsch und betroffenen Services anlegen.
Klassifizieren: Standard, Hotfix, Emergency oder Platform Release.
Pruefen, ob ein Freeze, regulatorische Frist oder Betriebsrestriktion relevant ist.
Release-ID, Zielumgebung und geplantes Release-Fenster vergeben.

2. Impact-Analyse

Betroffene OIM-Objekte identifizieren: Prozesse, Skripte, Templates, Synchronisationsprojekte, Rollen, Attestation, Web/API, Job Service, DB-Schema.
Abhaengigkeiten pruefen: andere Changes, OIM-Version, Datenmodell, Zielsysteme, Schnittstellen, AD/AAD/SAP/HR-Systeme.
Risiko bewerten: Datenveraenderung, Provisioning-Wirkung, Berechtigungsvergabe, Performance, Betriebsstabilitaet.
Test- und Rollback-Ansatz definieren.

3. Build und Packaging

Umsetzung nur in Dev oder dedizierter Build-Umgebung.
Technische Aenderungen mit Change-Log und betroffenen Objekten dokumentieren.
OIM Transportpaket nach Projektstandard erstellen, zum Beispiel ueber Database Transporter oder versionabhaengige Transportwerkzeuge.
Release-Manifest erstellen mit Paketname, Version, Quelle, Zielumgebungen, Prerequisites und Importreihenfolge.
Falls erforderlich: DB-Kompilierung, Skriptkompilierung, Konsistenzpruefung und Konfigurationsvalidierung einplanen.

4. Test und Abnahme

Transport in Test importieren, Importprotokoll sichern und technische Smoke Tests ausfuehren.
Pflichtchecks:
Job Queue und DBQueue ohne kritische Fehler.
Job Services erreichbar und verarbeiten Jobs.
Synchronisationsprojekte starten und liefern erwartete Ergebnisse.
Provisioning oder Deprovisioning wirkt nur im definierten Scope.
Web Portal, API und zentrale Manager-/Designer-Funktionen sind verwendbar.
Berechtigungs-, Rollen- und Genehmigungslogik erfuellt Akzeptanzkriterien.
UAT mit Business Process Owner und dokumentierter Abnahme abschliessen.

5. Go-Live Vorbereitung

Wartungsfenster, Kommunikationsplan und Freeze-Regeln bestaetigen.
Aktuelles DB-Backup, Restore-Faehigkeit und benoetigte Infrastruktur-Zugriffe pruefen.
Importreihenfolge, Verantwortliche, Zeitplan, Pruefschritte und Eskalationskontakte festlegen.
CAB- oder Change-Freigabe einholen.
Betriebsuebergabe vorbereiten: Monitoring, Runbook, Known Issues, Supportkontakt, Hypercare-Dauer.

6. Produktion und Hypercare

Vor Deployment: kritische Scheduler, Sync-Jobs oder Integrationslaeufe gemaess Go-Live-Plan pausieren.
Transport importieren und Importprotokoll speichern.
Nach Deployment: Kompilierung, Service-Neustarts und Cache-/Web-App-Schritte gemaess Release-Plan ausfuehren.
Smoke Tests in Produktion dokumentieren.
Queue, Sync, Provisioning, Web/API, Application Server und Zielsystemrueckmeldungen ueberwachen.
Release erst schliessen, wenn Abnahme, Betriebsuebergabe und Restpunkte dokumentiert sind.

Quality Gates

Gate	Zeitpunkt	Mindestnachweis
G1 Scope Ready	Vor Build	Requirement, Scope, Risiko, Akzeptanzkriterien
G2 Build Ready	Vor Testimport	Change-Log, Transportpaket, Release-Manifest
G3 Test Ready	Nach Testimport	Importprotokoll, technische Smoke Tests, Defect-Status
G4 Release Ready	Vor CAB/Prod	UAT-Abnahme, Rollback-Plan, Go-Live-Plan
G5 Operate Ready	Nach Prod	Produktions-Smoke-Test, Monitoring, Runbook, Hypercare

RACI Matrix

R = Responsible, A = Accountable, C = Consulted, I = Informed

Aktivitaet	Release Manager	OIM Technical Lead	OIM Developer	QA/Test	Business Owner	IAM Operations	Change Manager/CAB	DB/Infrastructure	Security/Compliance
Requirement erfassen	A	C	I	I	R	I	I	I	C
Release klassifizieren	A	R	C	I	C	C	C	I	C
Impact-Analyse	C	A	R	C	C	C	I	C	C
Scope und Akzeptanzkriterien	A	C	C	C	R	I	I	I	C
Implementierung in Dev	I	A	R	I	C	I	I	C	C
Transportpaket erstellen	C	A	R	I	I	C	I	C	I
Testplan und Testdaten	C	C	C	A	C	C	I	I	C
Technische Tests	I	A	R	R	I	C	I	C	I
UAT und fachliche Abnahme	C	C	I	C	A/R	I	I	I	C
Go-Live- und Rollback-Plan	A	R	C	C	I	C	C	C	C
CAB-Freigabe	R	C	I	I	C	C	A	C	C
Produktionsdeployment	A	R	C	I	I	R	I	R	I
Post-Deployment Smoke Test	A	R	C	C	C	R	I	C	I
Hypercare und Betriebsuebergabe	A	C	C	I	I	R	I	C	I
Release Closure	A/R	C	C	C	C	C	I	I	I

Release Manifest

Feld	Inhalt
Release-ID	Eindeutige ID, zum Beispiel OIM-RM-YYYY-NNN
Release-Name	Kurzname des Release
Release-Art	Standard, Hotfix, Emergency, Platform
OIM-Version	Produktversion, Service Pack, kundenspezifische Build-Info
Paket(e)	Dateiname, Version, Hash oder Ablageort
Importreihenfolge	Reihenfolge aller Pakete und manuellen Schritte
Betroffene Komponenten	Prozesse, Skripte, Sync, Web, DB, Zielsysteme
Prerequisites	Backup, Rechte, Wartungsfenster, gestoppte Scheduler
Testnachweise	Testfall-IDs, Smoke-Test-Protokoll, UAT
Rollback	Backup, Restore, Ruecktransport, Fix-forward oder manuelle Korrektur
Betriebsuebergabe	Monitoring, Runbook, Known Issues, Hypercare

Requirements Template

---
title: OIM Release Requirement - <Kurztitel>
tags: oneim, release-requirement, change
---

# OIM Release Requirement - <Kurztitel>

## Stammdaten

| Feld | Wert |
| --- | --- |
| Requirement-ID | OIM-REQ-YYYY-NNN |
| Release-ID | OIM-RM-YYYY-NNN |
| Owner |  |
| Business Process Owner |  |
| Release-Art | Standard / Hotfix / Emergency / Platform |
| Zielumgebung | Dev / Test / PreProd / Prod |
| Zieltermin |  |
| Prioritaet | Low / Medium / High / Critical |
| Status | Draft / In Analysis / Build / Test / Approved / Released / Closed |

## Business-Ziel

- Welches fachliche Problem wird geloest?
- Welcher Service, Prozess oder welche Benutzergruppe ist betroffen?
- Welcher messbare Nutzen oder welches Risiko wird adressiert?

## Scope

### In Scope

- 

### Out of Scope

- 

## OIM Impact

| Bereich | Betroffen? | Details |
| --- | --- | --- |
| Datenmodell / Tabellen | Ja/Nein |  |
| Skripte / Templates | Ja/Nein |  |
| Prozesse / Job Service | Ja/Nein |  |
| Synchronization Engine | Ja/Nein |  |
| Rollen / Berechtigungen | Ja/Nein |  |
| Attestation / Rezertifizierung | Ja/Nein |  |
| Web Portal / API | Ja/Nein |  |
| Reports | Ja/Nein |  |
| Zielsysteme | Ja/Nein |  |
| Betrieb / Monitoring | Ja/Nein |  |

## Abhaengigkeiten

- Technische Abhaengigkeiten:
- Fachliche Abhaengigkeiten:
- Release-Abhaengigkeiten:
- Infrastruktur- oder Rechteanforderungen:

## Akzeptanzkriterien

- [ ] 
- [ ] 
- [ ] 

## Testanforderungen

| Testtyp | Erwarteter Nachweis |
| --- | --- |
| Unit/Developer Test |  |
| Technischer OIM Smoke Test |  |
| Integrationstest |  |
| UAT |  |
| Regressionstest |  |

## Datenmigration und Betriebsfolgen

- Datenkorrektur oder Migration erforderlich:
- Geplante Laufzeit:
- Auswirkungen auf Job Queue, DBQueue oder Synchronisation:
- Monitoring nach Go-Live:

## Rollback / Recovery

- Primaerer Rollback-Ansatz:
- Backup-/Restore-Anforderung:
- Fix-forward Option:
- Entscheidungszeitpunkt fuer Rollback:
- Verantwortliche Person:

## Dokumentation und Uebergabe

- [ ] Release Notes aktualisiert
- [ ] Runbook aktualisiert
- [ ] Monitoring angepasst
- [ ] Support / Managed Service informiert
- [ ] Known Issues dokumentiert

## Freigaben

| Rolle | Name | Datum | Entscheidung |
| --- | --- | --- | --- |
| Business Owner |  |  |  |
| OIM Technical Lead |  |  |  |
| IAM Operations |  |  |  |
| Change Manager / CAB |  |  |  |
| Security / Compliance falls relevant |  |  |  |

Definition of Done

Release Requirement ist vollstaendig und freigegeben.
Transportpakete und Release-Manifest sind abgelegt und versioniert.
Testimport, technische Smoke Tests und UAT sind dokumentiert.
Go-Live-Plan, Rollback und Kommunikationsplan sind freigegeben.
Produktionsdeployment ist protokolliert.
Hypercare ist abgeschlossen oder an Betrieb uebergeben.
Lessons Learned und offene Restpunkte sind dokumentiert.