Production in CI/CD — was es ist, Phasen und Umgebung in der Entwicklung

Was ist Production in CI/CD

Production im Kontext von CI/CD ist die letzte Phase des Anwendungslebenszyklus, in der der Code nach dem Durchlaufen aller Build- und Testphasen für Endbenutzer verfügbar wird. Anders als Entwicklungs- und Staging-Umgebungen arbeitet die Produktionsumgebung mit echten Daten und Lasten, was besondere Anforderungen an Zuverlässigkeit und Leistung stellt.

Rolle der Produktionsumgebung

Die Produktionsumgebung ist nicht nur ein Server, sondern eine gesamte Infrastruktur, die Load-Balancer, Datenbanken, Caching-Schichten, CDN und Überwachungssysteme umfasst. Jede Komponente muss ausfallsicher und skalierbar sein. In der mobilen Entwicklung umfasst Production auch Backend-Dienste, API-Gateways und Push-Infrastruktur, die die Client-Anwendung unterstützen.

Anforderungen an die Produktionsumgebung

Die Produktionsumgebung muss strenge Kriterien erfüllen: Verfügbarkeit von 99,9 % und höher, API-Antwortzeit nicht mehr als 200 ms, Unterstützung der Notfallwiederherstellung (RTO und RPO innerhalb des SLA). Für mobile Anwendungen werden zusätzlich Crash-Reporting, Nutzungsanalysen und A/B-Plattformen für Experimente benötigt. Die CI/CD-Pipeline stellt die Einhaltung dieser Anforderungen durch automatisierte Prüfungen vor jedem Deployment sicher.

Phasen des Deployment in Production

Das Deployment in Production ist ein mehrstufiger Prozess, der durch die CI/CD-Pipeline automatisiert wird. Jede Stufe enthält Prüfungen, die verhindern, dass fehlerhafter Code in Production gelangt. Lassen Sie uns die wichtigsten Phasen am Beispiel einer typischen Pipeline für mobile Anwendungen betrachten.

CI/CD-Pipeline für Production

Die Pipeline beginnt mit einem Commit in den Hauptzweig des Repositorys. Nach dem Push werden automatischer Build und Unit-Tests gestartet, gefolgt von Integrationstests und Code-Qualitätsprüfungen. Nach erfolgreichem Abschluss aller Phasen wird das Artefakt in der Build-Registry veröffentlicht und zur endgültigen Überprüfung in Staging bereitgestellt. Erst nach Bestätigung im Staging fährt die Pipeline mit dem Deployment in Production fort.

@Library("shared-lib") _

pipeline {
    agent any

    stages {
        stage("Build") {
            steps {
                sh "cd app && ./gradlew assembleRelease"
            }
        }
        stage("Test") {
            steps {
                sh "cd app && ./gradlew testRelease"
            }
        }
        stage("Deploy to Staging") {
            steps {
                sh "deploy-staging.sh"
            }
        }
        stage("Deploy to Production") {
            input "Deploy to production?"
            steps {
                sh "deploy-production.sh"
            }
        }
    }
}

Deployment-Automatisierung

Das automatisierte Deployment in Production verwendet Zero-Downtime-Deployment-Strategien: Rolling Update, Blue-Green-Deployment oder Canary Release. Beim Rolling Update ersetzen neue Anwendungsinstanzen schrittweise alte, ohne den Dienst zu unterbrechen. Blue-Green-Deployment unterhält zwei identische Umgebungen und wechselt den Datenverkehr sofort, was bei Problemen eine schnelle Rücknahme ermöglicht. Die Wahl der Strategie hängt von der Kritikalität des Dienstes und der akzeptablen Ausfallzeit ab. Für mobile Anwendungen umfasst das Deployment in Production die Veröffentlichung in App-Stores (App Store Connect, Google Play Console) mit schrittweisem Rollout, was eine zusätzliche CI/CD-Integration mit Store-APIs erfordert, um den Veröffentlichungsprozess zu automatisieren, einschließlich Hochladen von Binärdateien, Ausfüllen von Metadaten und Einreichen zur Überprüfung.

Post-Deployment-Prüfungen

Nach erfolgreichem Deployment in Production startet die CI/CD-Pipeline eine Reihe von Smoke-Tests, die die grundlegende Dienstfunktionalität überprüfen: Endpunktverfügbarkeit, Korrektheit der API-Antworten, Antwortzeit innerhalb normaler Grenzen. Für mobile Anwendungen werden zusätzlich die Autorisierungsfähigkeit, Datensynchronisation und korrekte Funktion von Zahlungsintegrationen geprüft. Wenn Smoke-Tests fehlschlagen, initiiert die Pipeline automatisch ein Rollback auf die vorherige stabile Version und sendet eine Benachrichtigung an das Team. Die Post-Deployment-Überwachung wird 30-60 Minuten mit erhöhtem Alarmniveau fortgesetzt — dies ist das Fenster zur Erkennung von Problemen, die nicht von automatischen Tests abgedeckt werden.

Unterschiede zwischen Production und Testumgebungen

Der Hauptunterschied zwischen Production und weniger strengen Umgebungen besteht in der Arbeit mit echten Benutzerdaten und -lasten. Die Staging-Umgebung ist für abschließende Tests vor der Veröffentlichung konzipiert, verwendet jedoch synthetische oder anonymisierte Daten. Production hingegen verarbeitet Live-Transaktionen, persönliche Daten und kritisch wichtige Operationen, was einen grundlegend anderen Management-Ansatz erfordert.

Konfiguration und Infrastruktur

Die Konfiguration der Produktionsumgebung muss streng von anderen Umgebungen isoliert sein. Dies gilt für Umgebungsvariablen, Datenbankverbindungszeichenfolgen, API-Schlüssel und Zertifikate. Die Produktionsinfrastruktur wird normalerweise über mehrere Verfügbarkeitszonen dupliziert, um Ausfallsicherheit zu gewährleisten. Für mobile Anwendungen umfasst Production auch Apple App Store- und Google Play-Konfigurationen, die in Test-Builds fehlen.

Datenmanagement

In Production ist die Verwendung echter Daten für Tests strengstens untersagt — dafür gibt es Staging- und Entwicklungsumgebungen. Alle Änderungen an der Datenbank-Struktur müssen Migrationen durchlaufen, die von der CI/CD-Pipeline automatisch angewendet werden. Die Sicherung der Produktionsdaten erfolgt nach einem Zeitplan mit automatischer Integritätsprüfung. Die Aufbewahrungsrichtlinie bestimmt die Speicherdauer der Backups gemäß den GDPR-Anforderungen und anderen Vorschriften.

Überwachung der Produktionsinfrastruktur

Produktionsüberwachung ist ein kontinuierlicher Prozess der Erfassung und Analyse von Metriken, Logs und Traces. Ohne umfassende Überwachung ist es unmöglich, SLA zu garantieren und Vorfälle rechtzeitig zu erkennen. Der moderne Ansatz zur Überwachung basiert auf drei Säulen: Metriken (numerische Indikatoren), Logs (strukturierte Ereignisaufzeichnungen) und Traces (Anfrageverfolgung).

Wichtige Metriken

Zu den wichtigsten Metriken der Produktionsumgebung gehören: Uptime (Dienstverfügbarkeit), Latenz (Antwortverzögerung), Fehlerrate (Prozentsatz der Fehler), Durchsatz (Bandbreite) und Sättigung (Ressourcenauslastung). Für mobile Anwendungen sind Startzeitmetriken, fehlerfreie Rate und Datensynchronisationszeit kritisch. Alarme werden basierend auf SLOs (Service Level Objectives) konfiguriert, damit das Team Benachrichtigungen erhält, bevor das SLA verletzt wird.

Überwachungswerkzeuge

Für die Überwachung der Produktionsinfrastruktur werden spezialisierte Plattformen verwendet: Datadog, New Relic, Grafana + Prometheus zur Metrikenerfassung, Sentry und Crashlytics zur Fehlerverfolgung in mobilen Anwendungen. Logs werden über den ELK-Stack (Elasticsearch, Logstash, Kibana) oder Splunk zentralisiert. Die Anfrageverfolgung wird mit Jaeger oder Zipkin implementiert. Alle Tools sind für die automatische Dashboard-Erstellung bei der Bereitstellung eines neuen Dienstes in die CI/CD-Pipeline integriert. Das Incident-Response-System (PagerDuty, Opsgenie) empfängt Alarme von allen Überwachungstools und weist basierend auf Rotations- und Eskalationsregeln automatisch eine verantwortliche Bereitschaftsperson zu. Ein Runbook für jeden Vorfalltyp wird im Repository gespeichert und zusammen mit dem Code versioniert, was die Aktualität der Wiederherstellungsanweisungen gewährleistet.

Sicherheit der Produktionsumgebung

Die Sicherheit der Produktionsumgebung ist ein mehrschichtiges Schutzsystem, das Infrastruktur, Daten, Zugriff und den Bereitstellungsprozess abdeckt. Jede Schicht muss so konfiguriert sein, dass die Kompromittierung einer Schicht nicht zur Kompromittierung des gesamten Systems führt. Die CI/CD-Pipeline spielt eine Schlüsselrolle bei der Gewährleistung der Sicherheit durch automatisierte Prüfungen, Schwachstellenscans und Compliance-Kontrolle in jeder Pipeline-Stufe.

Zugriff und Rollen

Der Zugriff auf die Produktionsumgebung ist nach dem Prinzip der geringsten Privilegien streng eingeschränkt. Entwickler haben keinen direkten Zugriff auf Produktionsserver — alle Änderungen durchlaufen die CI/CD-Pipeline mit einem Genehmigungsmechanismus. Für Notfallzugriffe werden temporäre Anmeldeinformationen mit automatischer Rotation und vollständiger Aktionsprotokollierung verwendet. Das Vier-Augen-Prinzip (jede Operation erfordert die Genehmigung von zwei Personen) ist der Standard für Produktionsvorgänge.

Änderungsprüfung

Jede Änderung in Production wird im Prüfsystem aufgezeichnet: wer das Deployment initiiert hat, welcher Commit bereitgestellt wurde, welche Prüfungen bestanden wurden, wie lange das Deployment dauerte. Die Integration von CI/CD mit Incident-Management-Systemen (PagerDuty, Opsgenie) ermöglicht die automatische Ticket-Erstellung bei fehlgeschlagenem Deployment oder SLO-Verletzung. Alle Produktionslogs werden in einem unveränderlichen Repository mit einer Aufbewahrungsdauer von mindestens 90 Tagen gemäß den SOC2- und ISO-27001-Anforderungen gespeichert.