Projektmanagement & ITIL
Release Management
Overview
Release Management macht neue und geänderte Services und Funktionen für die Nutzung verfügbar. ITIL 4 hat den früheren Prozess Release and Deployment Management aufgeteilt: Release Management entscheidet, was in einem Release enthalten ist und wann es für Anwender freigegeben wird. Deployment Management bringt Komponenten technisch in Zielumgebungen. Beide sind auch in ITIL (Version 5) eigene Practices.
Der Unterschied ist wichtig, weil moderne Verfahren beides entkoppeln: Code kann längst produktiv ausgerollt sein, aber erst später per Feature-Flag für Anwender freigeschaltet werden.
In Microsoft-365-Umgebungen steuert Microsoft die Releases, Du steuerst nur die Release-Präferenzen. Wichtige Änderung: Targeted Release wird laut Microsoft Learn im Januar 2027 eingestellt, ab November 2026 sind keine neuen Zuordnungen mehr möglich. An seine Stelle treten Frontier, Standard Release und Deferred Release. Für Microsoft 365 Apps gelten weiterhin die Update-Kanäle.
How it works
Typischer Ablauf eines Releases:
- Release planen: Inhalt, Termin, Abhängigkeiten, Kommunikation.
- Bauen und testen: Build, Integrations- und Abnahmetests in einer Testumgebung.
- Freigabe über Change Enablement bzw. Approvals und Checks in der Pipeline.
- Ausrollen in Ringen oder Wellen, z. B. zuerst IT, dann Pilotgruppe, dann alle.
- Validieren mit Monitoring, gegebenenfalls Rollback.
- Kommunizieren und dokumentieren: Release Notes, Schulung, Wissensartikel.
Werkzeuge sind z. B. Azure Pipelines (YAML-Pipelines mit Environments und Checks oder klassische Release Pipelines) und GitHub Actions.
Benefits
- Planbare Veränderungen für Anwender, weil Termine und Inhalte vorher bekannt sind.
- Geringeres Risiko durch Tests und gestaffelte Verteilung, Fehler treffen zuerst eine kleine Gruppe.
- Schnelle Rücknahme durch definierte Rollback-Verfahren.
- Bessere Akzeptanz durch Release Notes und Schulungen im Vorfeld.
Practical example
Ein Hersteller von Messtechnik entwickelt eine interne Auftragsapp und rollt sie bisher manuell auf einen Webserver aus. Mit Azure Pipelines führt die IT drei Environments (Test, Pilot, Produktion) mit Freigabe durch den Fachbereich vor der Produktionsstufe ein. Releases erscheinen nun alle zwei Wochen mit Release Notes im Teams-Kanal. Für Microsoft 365 setzt die IT parallel die neuen Release-Präferenzen, bevor Targeted Release entfällt.
Things to keep in mind
- Prüfe vor November 2026 die Release-Präferenzen im Microsoft 365 Admin Center und richte Frontier, Standard oder Deferred bewusst ein.
- Trenne Deployment und Freigabe, wo möglich, um Releases ohne Ausfallzeit zurücknehmen zu können.
- Verteile in Ringen und definiere vorher, welche Fehler einen Stopp auslösen.
- Stimme Releases mit dem Change-Kalender ab, damit nicht mehrere riskante Änderungen zusammenfallen.
Conclusion
Release Management bündelt Änderungen zu planbaren, getesteten Paketen und macht ihre Einführung kontrollierbar. Für Microsoft 365 steht mit dem Ende von Targeted Release eine konkrete Umstellung an.
Further reading
Related articles
Microsoft 365
Microsoft Purview | Data Lifecycle Management: Retention Labels
Exchange Online
PowerShell | ExchangeOnlineManagement 3.10.1 Becomes Mandatory
Microsoft 365
Microsoft Purview | Data Lifecycle Management: Publish labels (Label Policy)
Microsoft 365