Kontinuierliche Bereitstellung

1) Was ist eine CD und wie unterscheidet sie sich von einer CI/CD?

Kontinuierlicher Einsatz (Continuous Deployment, CD) ist die Praxis, jeden geprüften Wechsel automatisch in den Prod zu rollen, ohne manuelle „Release-Züge“. Von CI (automatische Builds und Tests bei Commits) unterscheidet sich die CD dadurch, dass sie die Kette vervollständigt: Code → Artefakt → Verifizierung → Produktion. In regulierten Branchen werden CDs oft mit progressiver Auslieferung (stufenweise Veröffentlichung mit Publikumsbeschränkung) kombiniert.

• Reduzieren Sie Time-to-Market und die Kosten für Änderungen.
• Reduzieren Sie das Risiko großer Releases: Kleine Chargen → einfacher, die Ursache zu finden und zurückzurollen.
• Legen Sie die Disziplin der Qualität fest: „Jedes Commit ist potenziell kommerziell“.

2) Grundprinzipien

Kleine Inkremente. Kurze Fiche-Zweige, schnelle Revue, aggressives Merjing.
Determinität der Montage. Wiederholbare Build-Umgebungen, Lock-Dateien, hermetische Builds.
Shift-Left-Qualität. Linters, statische Analyse, Unit/Contract Tests vor der Integration.
Produktionsähnliche Umgebung. Identische Configs, Geheimnisse durch Vault, Daten - synthetisch/unpersönlich.
Automatisierung des gesamten Weges. Von Commit über Traffic-Routing bis hin zu Rollback.
Standardbeobachtbarkeit. Metriken, Protokolle, Traces, Alerts - als Teil von Definition of Done.
Sicherheit durch Design. SAST/DAST, SCA, signierte Artefakte, Richtlinienprüfung.

3) Referenzarchitektur der Pipline-CD

1. Trigger: Ereignis im VCS (Push/Merge), gekennzeichnet als „prod-eligible“.
2. Build: Assembly des Artefakts (Bild, Paket), SBOM, Signatur (Sigstore/Cosign).
3. Test Fast: Lint/Unit/Contract; schnelles Feedback (<5-10 min).
4. Test Deep (parallel): Integration, E2E, Belastung „nach Profil“, Chaos-Tests im Stage.
5. Sicherheitstor: SAST/DAST/SCA, Geheimnisprüfung, Richtlinienprüfung (OPA/Conftest/Kyverno).
6. Compliance Gate: SoD/4-Augen bei Bedarf, Rückverfolgbarkeit der Anforderungen, Checklisten.
7. Promote: Förderung eines Artefakts als das gleiche Bild durch Umgebungen (dev → stage → prod).
8. Deploy Strategy: blue-green / canary / progressive + feature flags.
9. Post-Deploy Verification: Auto-Health, SLO/SLA, Alerts, Auto-Rollback beim Abbau.
10. Audit & Evidence: Artefakte, Protokolle, Prüfprotokolle - in einem unveränderlichen Speicher.

4) Veröffentlichungsstrategien

Blau-Grün: zwei Prod-Stände (Blau = aktuell, Grün = neu), atomare Leitwegschaltung. Plus - sofortiger Rollback. Der Nachteil ist die doppelte Infrastruktur.
Canary: Portionierter Traffic-Start (1% → 5% → 25% → 100%) mit automatischen SLO-Gates.
Progressive Lieferung: Zielkohorten (Region, Anbieter, VIP-Segment), Begrenzung des betroffenen Radius.
Feature Flags: Code-Lieferung „aus“, Aktivierung durch Benutzer/Kohorte. Obligatorisch: „Flag Lifecycle“ -Politik.

5) Prüfung und Qualität

Vertragstests und verbrauchergetriebene Verträge für unabhängige Microservices Releases.
Lastprofile nach realen Mustern (RPS, p95/p99, offene/geschlossene Modelle).
DB-Migrationstests: direkt/reversibel, Kompatibilität der beiden Versionen (Expand → Contract).
Chaos/Resilienz-Tests: Abhängigkeiten deaktivieren, Netzwerkverzögerungen, Ressourcenlimits.
Nachkontrolle (Rauch + synthetisch) von Punkten in der Nähe des Benutzers.

6) Sicherheit und Compliance in CD

Signatur der Artefakte, Provenance, SBOM. Wir verfolgen die Herkunft, schließen „supply chain“ -Risiken aus.
Policy-as-Code: Wir lassen nur Bilder aus einer vertrauenswürdigen Registrierung mit Scan-Pass zum Prod zu.
Geheimnisse: short-lived Token, rotierende Schlüssel, KMS; Verbot von Geheimnissen in der Gita.
Aufgabenteilung (SoD): Entwicklung ≠ Prod-Zugriff; Alle Operationen sind über die Pipeline.
Audit-Fußabdruck: unveränderliche Protokolle der Releases, wer/was/wann; N Jahre für regulatorische Zwecke.

7) Änderungsmanagement und Risikokontrolle

Änderungstypen: Standard (vollautomatisch), normal (Auto + Zulassung), Notfall (beschleunigtes Fenster + Post-Mortem).
CAB-Minimalismus: CABs für veränderte Risiken und infrastrukturelle „Breaking“ -Updates, der Rest durch automatische Quality Gates.
Risk Matrix: Einfluss × Wahrscheinlichkeit → Strategieauswahl (Canary tiefer, Flags, zusätzliche Überwachung).
Runbooks & Playbooks: Klare Anweisungen für jede Art von Release und Rollback.

8) Beobachtbarkeit, SLO und Auto-Rollback

Goldene Signale: Latenz, Fehler, Sättigung, Verkehr; Geschäftsmetriken (Konversion, Einzahlung, Zahlungserfolg).
Guardrails: wenn p95> Schwelle, error rate↑, business- metrika↓ - auto-stop/rollback.
Release Dashboards: Widgets: versiya→metriki→flagi→kanareyechnyye des Traffic-Anteils.
Alertas: Geräuschunterdrückung, On-Call-Rotation, Kommunikation mit dem Incident Management.

9) CD-Metriken

DORA-Metriken: Deployrate, Lead Time for Changes, MTTR, Anteil der fehlgeschlagenen Releases.
Change-failure-rate auf Kohorten (nach Anbieter, Region, Gerät).
Gate-Durchlaufzeit: Wo sind die Engpässe (Sicherheitsscan, Integrationstests).
Cost-to-Release: Kosten einer Fensterminute, Infrastrukturaufschlag von Strategien (blau-grün vs canary).

10) Pullback-Muster und Kompatibilität

Auto-Rollback: Auf der Ebene des Routings (Traffic Switch) und/oder der Versionierung (K8s Rollout Undo).
DB-Migrationen: Strategie expand-migrate-contract, Ficha-Flags verbergen unzugängliche Felder.
Idempotency & Exactly-once-like: für Warteschlangen/Zahlungen - idempotency keys, deduplizierung.
Back-pressure und graceful degradation: Wenn degradiert, deaktivieren Sie nicht-funktionale Funktionen.

11) Praktisches Modell der Umgebung

GitOps-Ansatz: Der Zielzustand wird im Git gespeichert, der Controller wendet Manifeste an.
Umgebungen: 'dev' (schnell und schmutzig), 'stage' (prod-like, chaos-trials), 'prod-A/B' (blau-grün) oder 'prod' mit kanarischen Pools.
Isolation von Daten: Configs als Daten, Geheimnisse außerhalb des Bildes, individuelle Lektionen/Grenzen.

12) Prozesse und Rollen

RACI: Architekt (Politiker), Plattformteam (Pipeline, Cluster), Produktteams (Tests/Flags), Sicherheit (Politiker/Scans), SRE (SLO/Zuverlässigkeit).
ChatOps: Releases von PR-Bots, Sichtbarkeit von Status, „/promote “, „/rollback“.
SOP: Release Checklisten, Post-Release Review, Kontrolle der „Aging“ -Flags.

13) Features für hochregulierte Domains (z.B. iGaming/Fintech)

Rückverfolgbarkeit: trebovaniye→tiket→PR→bild→artefakt→sreda→log im Audit.
Geo-Freigabe: nach Ländern/Jurisdiktionen, mit lokaler Zahlungskonfiguration/CUS.
Anti-Fraud/Risiko-Engines: kanarische Traffic-Pools, false-positive/negative Überwachung.
KYC/AML/Responsible Game: Fichi durch Flaggen mit obligatorischer Überwachung der Benutzerwirkung freigeben.

14) Häufige Anti-Muster

Manuelle Schritte zwischen den Stufen („brachten das Artefakt mit den Händen“).
„Graue Fahnen“ ohne Besitzer und Lebensdauer.
Ein gemeinsamer „dicker“ Integrationstest statt Verträge.
Keine reversiblen DB-Migrationen.
Sicherheitsscan nach dem Deploy, nicht vorher.

15) Mini-Checkliste für CD-Ready

• Bild deterministisch; das Artefakt ist signiert; Es gibt einen SBOM.
• Vertragstests und Fixturen für E2E.
• Security/Compliance-Gates als Code; Geheimnisse - durch den Tresor.
• Beobachtbarkeit: Logs/Metriken/Traces, Release Dashboards, SLO Gates.
• Release-Strategie: kanarisch/blau-grün + Auto-Rollback.
• Verfahren für DB-Migrationen (expand/contract).

Feature Flags mit der Richtlinie „erstellt → verwendet → gelöscht“.

• RACI/Runbooks/ChatOps Integration.

16) Beispielablauf (Szenario)

1. Merge in 'main' triggerite pipeline.
2. Behältermontage, Signatur, SBOM.
3. Lint/Einheit/Verträge → bestanden.
4. SAST/SCA/secret-scan → „grün“.
5. Auto-Promo auf der Bühne: E2E + Chaos + Profillast.
6. Kanarische 1% in prod, Fehler-/Latenzkontrolle/Geschäftsmetriken.
7. Eskalation auf 25 %/50 %/100% bei Green Gates.
8. „Rollout-Guard“ -Flag automatisch schließen, Audit-Artefakte aufzeichnen.
9. Post-Release Review, Entfernen von temporären Flags.

17) Das Ergebnis

Eine CD ist kein „Deploy Button“, sondern eine Kultur kleiner, sicherer und beobachtbarer Veränderungen. Mit den richtigen Policies und Automatisierungen reduziert die CD Risiken, beschleunigt die Wertlieferung und macht Releases zur Routine statt zum Event. Für hochbelastete und regulierte Systeme sind strenge Qualitätstore, phasenweise Rollout, Fitcha-Flags, Beobachtbarkeit und Reproduzierbarkeit jedes Schrittes der Schlüssel zum Erfolg.