Orchestrator/bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Draft-Release-Train-Technisches-Umsetzungskonzept-Automatisiertes-Multi-Team-Rel.md

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.