Betrieb und Verwaltung → Release- und Update-Zyklen

Release- und Update-Zyklen

1) Ernennung

• verringert die Unsicherheit und die Kosten der Koordinierung,
• verringert das Risiko von Zwischenfällen und Rückschlägen,
• synchronisiert die Technik mit Geschäftsereignissen (Marketing, Sport, Fin. Berichterstattung),
• erhöht throughput-Befehle ohne CFR-Wachstum (Change Failure Rate).

2) Releasemodelle: welche zu wählen

1. Release Train (Züge) - feste Slots (z.B. Di/Do 10:00 EET).

Geeignet für Multi-Team-Monolithen und „schwere“ Domänenänderungen.

2. Continuous Delivery (auf Anfrage) - jedes Merge, das die Quality-Gates passiert hat, kann in die Prod.

Geeignet für Microservices und Feature-Flag-Kultur.

3. Hybrid - Produktfronten auf Zügen, Backend-Services „on demand“.

Auswahlkriterien: Testreife/Beobachtungsfähigkeit, Abhängigkeit von externen Partnern (PSP/KYC), Compliance-Anforderungen, Organisationsgröße.

3) Releasekalender und Fenster

Einheitlicher Kalender (unternehmensweit): Releaseslots, DB-Migrationen, Marketingkampagnen, große Sportveranstaltungen, Berichtszeiträume.
Freeze-Perioden: klar definierte Fenster, in denen nur Hotfix P1 erlaubt ist (z.B. LF Finale, Black Friday, Steuererklärung).
Regionale Wellen: zuerst die „warmen“ Märkte/niedriger Verkehr, dann die wichtigsten; Nachtfenster der lokalen TZ.
Durchdringungsrichtlinie: Verbot gleichzeitiger Änderungen auf einem kritischen Pfad (Zahlungen, KYC, Autorisierung).

4) Verzweigung und Versionierung

Trunk-based + short-lived branches (Funktion Zweige ≤ 3-5 Tage).
Release-Zweig - nur für Züge/lange Prüfungen; hard back-merge in 'main'.
SemVer: `MAJOR. MINOR. PATCH 'für Bibliotheken/SDK; Tags von Artefakten und Umgebungen.
Verträge: Systeme (Avro/Protobuf) mit Back/Forward Kompatibilität; Migrationen sind zweiphasig.

5) Qualität canveers (Tore)

1. Static + SAST/DAST + Linters

2. Unit/Contract/Component Tests

3. E2E/Performance Smoke (auf dem Eis)

4. Sicherheits-/Compliance-Prüfungen (Geheimnisse, Lizenzen, territoriale Richtlinien)

5. Release Candidate → Signatur, SBOM, Artefakte

6. Progressives Rollout mit Auto-Gardrails (siehe § 7)

Alle Tore sind Code und Politik (Policy-as-Code), die Ergebnisse sind in Release-Artefakten.

6) Mittwoch und Promotion

Dev → Int → Stage → Prod, für Daten: Sandbox/Data-Stage.
GitOps Promotionen, immutable Bilder, Verbot von „manuellen“ Bearbeitungen in der Produktion.
Parametrierung: Regionen, Limits, Anbieter - über Configs (auditierbar).

7) Rollout-Strategien

Canary: 1%→5%→25%→100% (или per-region).
Blau-Grün: parallele Medien + atomare Umschaltung.
Feature Flags: Funktionsschalter/Kill-Schalter; A/B и shadow.
Staged Rollout Mobile/Web: nach Kundenversion/Zustellkanal (Store/OTA).

Gardrails (Auto-Stop): p95 Latenz ↑> 25%, Fehler%> 2%, Rückgang der Genehmigungen/Einlagen, Anstieg der Chargebacks, Burn-Rate SLO pro 1-Stunden-Fenster> Schwelle.

8) Abstimmung mit Unternehmen und Partnern

Marketing/Events: Funktionsfreigaben zu Kampagnen mit einem Vorrat ≥ 48 Stunden

Partner (PSP/KYC/Game-Anbieter): Slots für SDK-Zertifizierungen/Updates, doppelte Endpunkte für den Zeitraum der Migration.
Unterstützung: Makros/FAQs zu UX-Änderungen, Statusseiten, Eskalationskanäle.

9) Aktualisierungen von Daten und Schemata

Additiv zuerst: zuerst hinzufügen, dann Lesen/Schreiben wechseln, am Ende das Alte entfernen.
Indizes und große Migrationen sind Nachtfenster, durch Batches, mit Checkpoints und Fortschritt.
Versionierung von Schaufenstern und Metrikwörterbuch: Updates synchron zur Veröffentlichung, BI-Migrationen - getrennt von den Verkaufsfenstern.

10) Kommunikation und Artefakte

Release Notes (was/warum/Risiken/Rollback), ChangeLog nach Diensten.
Kalenderinvestitionen an Stakeholder, Anzeigenvorlagen (vor/während/nach).
War-Room-Kanal für die Zeit der Züge/große Releases, Frequenz der Upgrades: P1 - alle 15-20 min.

11) Leistungskennzahlen

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
Backout Rate nach Änderungstyp.
SLO Compliance% vor/nach Releases.
Release Debt: „hängende“ Flags, unvollständige Migrationen, alte Abhängigkeiten.
Business Impact: Conversion, KYC TTV, PSP Erfolg, GGR/NGR Drift zum Release-Fenster.

12) Anti-Muster

Big-bang: „alles auf einmal“ ohne Fahnen/Kanarienvögel.
Freigabe in der Spitze des Verkehrs/Ereignisse ohne Freeze-Ausnahmen.
Ohne Auto-Gardrails: manuelle Überwachung „am Auge“.
Langlebige Zweige: schmerzhafte Fusionen und versteckte Regressionen.
Manuelle Schritte in der Produktion: kein Audit und keine Vorhersehbarkeit.
Flaggen ohne TTL und Besitzer: „ewige“ Verzweigungen.

13) Checklisten

Vor der Veröffentlichung

• RFC/Ticket, Risk und Blast-Radius bewertet
• CI/CD Gates bestanden, Artefakte signiert
• Rollout-Plan + Stopp-Kriterien + Backout fertig
• Abstimmung mit Kalender, Freeze und Partnern
• Dashboards/Alerts sind an die Version gebunden, Kriegsraum erstellt

Während der Veröffentlichung

• Kanarienstufen und Auto-Stop aktiv
• Metriken p95/error%, Geschäftssignale (auth, KYC, PSP) auf dem Monitor
• Kommunikation nach Zeitplan, Status-Seite wird aktualisiert

Nach der Veröffentlichung

• Release Notes und ChangeLog veröffentlicht
• Flags entfernt/temporäre Ausnahmen (TTL)
• Post-mortem bei Abweichungen ≤ 5 Sklave. Tage
• Playbooks und Dokumentation aktualisiert

14) Mini-Vorlagen

• Datum/Uhrzeit: Di, 10: 00-12: 00 EET
• Bezirk: EU (10%→50%→100%), gefolgt von LATAM (10%→100%)
• Stoppkriterien: Fehler%> 2% 10 min, p95> + 25% 10 min, PSP-Erfolg <97%
• Backout: Traffic auf Vorgängerversion umschalten + Flags zurücksetzen
• Kontakt: @ RelEng, @ SRE-on-call, @ Support

• Was ist neu/Warum
• Auswirkungen auf Nutzer und Partner
• Risiken und bekannte Einschränkungen
• Rollout-Plan/Stop-Kriterien/Backout
• Metriken zur Überwachung
• Kontakte und Supportkanäle

15) Integration mit benachbarten Disziplinen

Change Management: Klassifizierung Standard/Normal/Emergency, CAB, Audit.
Reduzierung der Auswirkungen von Vorfällen: fertige Fitch-Flaggen, Quoten, Shedding.
Konfiguration Audit: Alle Promotions über Git, drift-detect und Application Log.
Ausführungsrichtlinien: Limits/Timeouts/Retrays - als Code, mit Zwang.

16) Das Ergebnis

Releasezyklen sind ein überschaubarer Rhythmus zwischen Geschwindigkeit und Zuverlässigkeit. Feste Zeitnischen, bei denen eine Koordinierung erforderlich ist; „on demand“, wo die Reife der Automatisierung. Überall - ein Kalender, Flaggen und Kanarienrollen, automatische Gardrails und transparente Kommunikation. So werden Releases berechenbar, sicher und wirtschaftlich.