# Draft - Release Train - Technisches Umsetzungskonzept: Automatisiertes Multi-Team Release Management

Version: 1 | Last modified: 2026-06-16T11:47:54.778+02:00
Source: confluence page ID 603274912

---

Status | YellowDRAFT
 | 
Rolle | Release Manager / System Architek | 
Zielgruppe | DevOps / Devs | 

1. Einleitung & Strategischer HintergrundÂ In einer modernen Microservice- oder lose gekoppelten Systemlandschaft, in der mehrere autonome Entwicklerteams parallel Features entwickeln, entstehen ohne klare Strukturen zwei Kernprobleme:
Das Integrations-Chaos: Teams deployen unkoordiniert. Stille AbhÃ¤ngigkeiten zwischen Services brechen erst auf hÃ¶heren Umgebungen oder â im schlimmsten Fall â auf der Produktion.
Der Dokumentations-Overhead: Entwickler verbringen wertvolle Zeit damit, Excel-Listen zu pflegen, Jira-Tickets manuell zu schieben und Confluence-Release-Notes hÃ¤ndisch zu tippen. Das ist fehleranfÃ¤llig und intransparent.
Unsere VisionWir entkoppeln die Entwicklungsgeschwindigkeit von der Produktions-Governance.
Auf den vorderen Umgebungen (DEV bis TEST) gilt das Prinzip der maximalen Autonomie: Teams dÃ¼rfen und sollen so oft, so frei und so schnell wie mÃ¶glich deployen, um schnelles Feedback zu generieren.
Auf den hinteren Umgebungen (ABNAHME bis PRODUKTION) gilt das Prinzip der eisernen StabilitÃ¤t, vollstÃ¤ndigen Transparenz und rigorosen Automatisierung. Wir fÃ¼hren das âRelease Trainâ-Modell ein. Die Produktion wird nicht mehr ad hoc bespielt, sondern ausschlieÃlich in zwei festen Wartungsfenstern: Dienstag und Donnerstag. Wer die automatisierten und fachlichen QualitÃ¤tskriterien (Quality Gates) bis zum jeweiligen Stichtag nicht erfÃ¼llt, verpasst den âZugâ und wartet automatisch auf den nÃ¤chsten (z.B. von Dienstag auf Donnerstag). Es gibt keine kÃ¼nstlichen VerzÃ¶gerungen fÃ¼r die Gesamtheit des Systems, nur weil eine einzelne Komponente verzÃ¶gert ist.
2. Die Kubernetes Stage-Infrastruktur & Quality GatesWir betreiben fÃ¼nf dedizierte Kubernetes-Cluster (oder logisch strikt getrennte Namespaces), die als fortlaufende Stufen unserer Pipeline dienen. Jede Stufe besitzt ein definiertes Einlasskriterium (Quality Gate).
2.1 DEV (Development)Zweck: Kontinuierliche Integration (CI) fÃ¼r Entwickler-Feedback.
AuslÃ¶sung: Jeder Push auf einen Feature-Branch oder offenen Merge Request (MR).
Automatisches Quality Gate:Erfolgreicher Build des Docker-Images.
Code-Linting bestanden.
Unit-Tests erfolgreich (Coverage > 80%).
Statische Codeanalyse (SAST / SonarQube) ohne kritische Befunde.

Verhalten: Automatisches Deployment in den Dev-Namespace nach erfolgreichem Gate.
2.2 IEU (Integrierte Entwicklungsumgebung)Zweck: Erste technische Validierung des Zusammenspiels loser gekoppelter Services.
AuslÃ¶sung: Automatischer Trigger nach einem erfolgreichen Merge auf den Hauptzweig (main / master).
Automatisches Quality Gate:Consumer-Driven Contract Testing (CDCT): AusfÃ¼hrung von VertrÃ¤gen (z.B. via Pact). Wenn Team A eine API-Schnittstelle so verÃ¤ndert, dass der Konsumenten-Service von Team B bricht, scheitert diese Pipeline sofort. Der Merge wird blockiert.
Technische API-Integrationstests (z.B. automatisierte Postman/Newman-Kollektionen).

2.3 INT (Integrierte Testumgebung mit Drittsystemen)Zweck: Vollwertige Fach- und End-to-End-Tests in einer verketteten Umgebung, die mit echten externen Drittsystemen (z.B. Zahlungsanbieter-Sandboxen, ERP-Testsystemen) kommuniziert.
AuslÃ¶sung: Automatisch nach erfolgreicher INT-Stage oder als periodischer Nightly-Build.
Quality Gate (Hybrid):Automatisch: Umfassende End-to-End (E2E) Test-Suiten (z.B. via Playwright oder Cypress).
Manuell/API: QA-Verantwortliche im jeweiligen Team kÃ¶nnen optionale manuelle Abnahmen via GitLab Manual Action bestÃ¤tigen.

Jira-Automatisierung: In Jira muss ein entsprechendes Label gesetzt werden
2.4 ABNAHME (Staging / Produktionsnah)Zweck: Letzte Bastion vor der Produktion. Die Umgebung spiegelt die Datenmenge, Skalierung und Konfiguration der Produktion wider (inkl. replica counts, ingress-Routen etc.).
AuslÃ¶sung: Manuell durch das Erstellen eines Release-Tags (z.B. v2.4.0-rc1) im Git-Repository.
Quality Gate (Fachliches Sign-Off):Automatisierte Last- und Performance-Tests.
Das fachliche Go: Die Product Owner (POs) mÃ¼ssen die User Stories auf dieser Umgebung prÃ¼fen und im Jira-Ticket das Custom-Feld Fachliche Abnahme auf Approved setzen.

2.5 PRODUKTION (Live-System)Zweck: Auslieferung des stabilen Wertes an den Endkunden.
AuslÃ¶sung: AusschlieÃlich Dienstag und Donnerstag innerhalb der definierten Wartungsfenster.
Striktes Quality Gate:Alle vorherigen Stages sind vollstÃ¤ndig grÃ¼n.
Automatischer API-Check: Gibt es offene Blocker-Tickets in Jira? Ist das Confluence-Readiness-Board im Status "GO"?
Vier-Augen-Prinzip: Das Deployment ist als geschÃ¼tzte manual action in GitLab hinterlegt. Nur die Rolle Release Manager (oder explizit autorisierte Lead Engineers) hat die Berechtigung, den finalen Deploy-Knopf in der Pipeline zu drÃ¼cken.

3. Der BPMN-Prozessfluss im DetailDie Orchestrierung Ã¼ber die Teams hinweg folgt einem klaren zeitlichen und prozessualen Rhythmus.
[Mo / Mi 15:00 Uhr] [Mo / Mi 16:00 Uhr] [Di / Do Wartungsfenster]
 â â â
 â¼ â¼ â¼
Pipeline scannt Jira âââ> Confluence-Ampel âââ> Release-Sync âââ> Finales Deploy
& prÃ¼ft AbhÃ¤ngigkeiten wird generiert (Go/No-Go) (RM Freigabe)

Montag & Mittwoch 15:00 Uhr (Einsendeschluss / Feature Freeze fÃ¼r den Release Train): Die Entwickler mÃ¼ssen alle Tickets, die am Folgetag live gehen sollen, im Jira-Projekt ihres Teams mit der entsprechenden fixVersion versehen haben (z.B. Release-2026-W24-Di). Alle zugehÃ¶rigen MRs mÃ¼ssen gemerged und auf der Abnahmeumgebung erfolgreich getestet sein.
Montag & Mittwoch 16:00 Uhr (Der automatisierte Readiness-Scan): Ein zentral gesteuerter GitLab-Pipeline-Job (Chron-Job) startet ein automatisiertes Skript. Dieses Skript aggregiert alle Jira-Daten, validiert AbhÃ¤ngigkeiten und schreibt einen visuellen Statusbericht (Ampelsystem) per REST-API direkt nach Confluence.
Montag & Mittwoch 16:15 Uhr (Das 15-Minuten-Release-Sync-Meeting): Ich als Release Manager lade die Lead-Entwickler oder Tech Leads der Teams zu einem ultrakurzen Sync ein. Wir Ã¶ffnen das automatisch generierte Confluence-Board. Wir diskutieren ausschlieÃlich Komponenten, die gelb oder rot markiert sind (z.B. weil Team B eine API-AbhÃ¤ngigkeit fÃ¼r Team A nicht rechtzeitig fertiggestellt hat).
Entscheidung: Entweder wird das Feature per Feature-Flag deaktiviert, oder die Komponente wird fÃ¼r diesen "Zug" ausgehÃ¤ngt (fixVersion wird auf das nÃ¤chste Fenster verschoben). Das fehlerfreie System der anderen Teams fÃ¤hrt planmÃ¤Ãig ab.
Dienstag & Donnerstag (Das Deployment): Zum Start des Fensters gebe ich das GitLab-Deployment manuell frei. Nach dem erfolgreichen Kubernetes-Rollout schlieÃt die Pipeline den Kreis, informiert die Stakeholder und setzt die Jira-Tickets automatisiert auf Done.
4. GitLab Pipeline Konzept & ArchitekturDie Pipelines der einzelnen Team-Repositories mÃ¼ssen standardisiert werden, um die beschriebene Logik abzubilden. FÃ¼r die Kommunikation mit Jira und Confluence wird ein zentrales Skript (z.B. in Python) genutzt, das als Docker-Image in die Pipelines eingebunden wird.

4.1 Fehler- und Rollback-Strategie (One-Click-Rollback)Sollte nach dem Prod-Deployment ein kritischer Fehler im Kubernetes-Cluster auftreten (erkannt durch Prometheus-Alerts oder Sentry), sieht das Pipeline-Design eine sofortige Schadensbegrenzung vor:
In der GitLab-OberflÃ¤che existiert neben dem fehlgeschlagenen/problematischen Produktions-Job ein âRollbackâ-Button (technisch ein helm rollback Befehl auf die vorherige stabile Revisionsnummer).
Das AuslÃ¶sen des Rollbacks triggert Ã¼ber das API-Skript sofort einen automatisierten Kommentar in allen zugehÃ¶rigen Jira-Tickets: â ï¸ ACHTUNG: Rollback auf Produktion durchgefÃ¼hrt. Feature vorerst wieder deaktiviert.
Ich als Release Manager werde sofort alarmiert, um die Task Force mit dem betroffenen Team zu koordinieren.
5. Jira & Confluence API-Schnittstellen-KonzeptDie Pipeline-Engineers mÃ¼ssen das Automatisierungsskript (check_jira_and_build_confluence_table.py) so programmieren, dass es folgende Endpunkte anspricht:
5.1 Jira REST API v3Das Skript nutzt JQL (Jira Query Language), um den Status aller Tickets einer Release-Version zu ermitteln.
Szenario 1: Tickets auslesenEndpunkt: GET /rest/api/3/search
Query: jql=fixVersion="Release-2026-W24-Di"
Validierungsschleife im Code:# Pseudo-Code zur PrÃ¼fung von Blockern und Sign-Offs
for ticket in response['issues']:
 # PrÃ¼fe fachliche Abnahme
 if ticket['fields']['customfield_10021']['value'] != "Approved":
 set_status_yellow(ticket['key'], "Fehlende fachliche Abnahme durch PO")

 # PrÃ¼fe verknÃ¼pfte Blocker
 for link in ticket['fields']['issuelinks']:
 if link['type']['name'] == "Blocks" and link['inwardIssue']['fields']['status']['name'] != "Done":
 set_status_red(ticket['key'], f"Blockiert durch unfertiges Ticket {link['inwardIssue']['key']}")

Szenario 2: Status-Update nach erfolgreichem DeploymentEndpunkt: POST /rest/api/3/issue/{issueIdOrKey}/transitions
Payload: {"transition": {"id": "ID_FUER_STATUS_DONE"}}
Zweck: Verschiebt alle Tickets vollautomatisch auf "Done", sobald das K8s-Deployment erfolgreich war.

5.2 Confluence REST APIDas Skript Ã¼bersetzt die gesammelten Jira-ZustÃ¤nde in ein valides XHTML-Format, das von Confluence nativ interpretiert werden kann. Um optisch ansprechende Status-Makros (die bekannten farbigen Status-Inseln) zu erzeugen, muss das Skript Confluence-Storage-Format-Tags generieren.
Endpunkt: PUT /wiki/rest/api/content/{pageId} (Update der existierenden Release-Wochenseite)
XHTML-Struktur fÃ¼r die Status-Ampel:<ac:structured-macro ac:name="status">
 <ac:parameter ac:name="title">GO</ac:parameter>
 <ac:parameter ac:name="colour">Green</ac:parameter>
</ac:structured-macro>

<ac:structured-macro ac:name="status">
 <ac:parameter ac:name="title">NO-GO</ac:parameter>
 <ac:parameter ac:name="colour">Red</ac:parameter>
</ac:structured-macro>

Das Skript baut aus diesen Bausteinen eine Ã¼bersichtliche Matrix-Tabelle aller Services und lÃ¤dt den HTML-Body via API hoch.
6. Zusammenfassung & NÃ¤chste Schritte fÃ¼r die Pipeline-EntwicklerMit diesem System beenden wir das Zeitalter der manuellen Berichterstattung. Entwickler tun das, was sie am besten kÃ¶nnen: Code schreiben und Git pflegen. Die Pipeline erledigt den bÃ¼rokratischen Rest. Arbeitspakete fÃ¼r das DevSecOps- / Pipeline-Team:
Paket 1: Erstellung des zentralen Python/Node-Docker-Images, das die Logik fÃ¼r die Jira- und Confluence-API-Kommunikation beinhaltet.
Paket 2: Einbau der CDCT/Pact-Test-Schritte in die test-Stage der Standard-Pipeline.
Paket 3: Konfiguration der geschÃ¼tzten Variablen (API-Tokens fÃ¼r Jira/Confluence) in den globalen GitLab-CI-Einstellungen.
Paket 4: Implementierung der when: manual Schranke fÃ¼r die Produktions-Infrastruktur-Pipelines mit Benutzerrollen-EinschrÃ¤nkung.
