Das eigentliche Problem sitzt in den meisten Entwicklungsteams im DACH-Markt beim Vertrauen: Deployments passieren selten, weil sie riskant sind. Manuelle Handgriffe, unklare Zuständigkeiten, Umgebungen, die von der Produktion abweichen, und Release-Fenster mit Wochenendbereitschaft sorgen dafür, dass jedes Deployment zum Wagnis wird. Je seltener ein Team deployt, desto mehr Änderungen stauen sich an. Der nächste Release wird dadurch riskanter, und das Team wartet länger auf den übernächsten.

Ordnung für die gewachsene Pipeline-Landschaft

Wir entwerfen CI/CD-Pipelines und DevOps-Praktiken, die ein Deployment im Alltag zum Routinevorgang machen. Die Arbeit beginnt beim Ist-Zustand, ob Jenkins mit 400 Build-Schritten, eine Sammlung von Bash-Skripten oder ein Bitbucket-zu-Produktion-Prozess, der nur im Kopf einzelner Personen existiert. Wir finden den Engpass und gestalten den Ablauf neu. Die neue Automatisierung verteilt die Last auf das ganze Team.

Pipeline-Design nach Teamgröße und Branching-Strategie

Zur Wahl stehen Trunk-based Development, wo es passt, und GitFlow, sofern Compliance-Vorgaben es verlangen. Bei Feature-Flag-basierten Releases mit Dark Launches wird eine neue Funktion zunächst nur für einen Teil der Nutzer sichtbar. Die Umsetzung erfolgt in GitHub Actions, GitLab CI oder der bestehenden Toolchain, mit Build-Caching und paralleler Testausführung von Anfang an eingeplant, ergänzt um Artefaktmanagement. Jede Pipeline durchläuft Build, Test, Sicherheitsprüfung, Staging und Freigabe für die Produktion, mit einer verantwortlichen Stelle und einem festen Vorgehen für jeden Fehlerfall.

GitOps und Deployment-Automatisierung

Mit GitOps-Workflows in ArgoCD oder Flux machen wir das Git-Repository zur einzigen verbindlichen Quelle für den Zustand von Anwendung und Infrastruktur. Ein Pull Request löst das Deployment aus, wo früher ein einzelner kubectl-Befehl oder eine SSH-Sitzung mitten in der Nacht genügte. Die Übergabe zwischen Umgebungen läuft deklarativ und nachvollziehbar ab, und ein Rollback dauert Sekunden, weil der vorherige Zustand jederzeit als Commit abrufbar ist. Das ist für Teams mit Kubernetes-Deployments die betriebliche Grundlage für Cluster-Management im großen Maßstab.

Developer Experience und DORA-Metriken als Signal für dein Team

Langsame CI belastet jeden Entwickler im Team, jeden Tag aufs Neue. Wir prüfen deshalb die Laufzeiten der Pipelines und suchen die Engpässe. Dabei stehen vier Werte im Fokus: Lead Time for Changes, Deployment Frequency, Mean Time to Restore und Change Failure Rate, die DORA-Metriken. Ein Quartalsbericht für das Management sagt darüber wenig aus. Diese Werte zeigen dem Team laufend, wo sich Investitionen in die Entwicklung auszahlen. Die Zielwerte richten sich nach deiner aktuellen Ausgangsbasis, ganz konkret für dein Team.

Umgebungsparität durch Infrastructure as Code und Konfigurations- sowie Zugangsdatenmanagement über Vault

Eine Staging-Umgebung, die von der Produktion abweicht, ist die häufigste Ursache für Deployment-Vorfälle. Konsistente Umgebungen halten das Risiko klein: automatisiert bereitgestellte, containerisierte Umgebungen und zentral verwaltete Zugangsdaten über HashiCorp Vault oder eine vergleichbare Cloud-native Lösung. Abweichungen in der Konfiguration werden dadurch sichtbar und korrigierbar, bevor sie zum Ausfall führen.

Sicherheitsprüfungen direkt in der Pipeline

Sicherheitsprüfungen außerhalb der Pipeline werden in der Praxis oft übersprungen. SAST (statische Codeanalyse), Dependency Scanning, Container Image Scanning und die Erkennung offengelegter Zugangsdaten laufen deshalb direkt im Build-Prozess. Ein Ergebnis blockiert je nach Schweregrad den Pull Request, oder er landet, vermerkt, in einem gemeinsamen Backlog, laufend sichtbar für das ganze Team.

Nachweis in der Produktion

Wer eine externe Pipeline-Transformation an geschäftskritischer Infrastruktur zulässt, verlangt zu Recht belastbare Nachweise. Die Zahlen in diesem Text kommen aus dem laufenden Betrieb realer Kundensysteme.

commercetools und die operative Verantwortung für eine globale Plattform

Unser Team übernimmt bei commercetools in Vietnam während der Tageszeit im asiatisch-pazifischen Raum im Rahmen eines Follow-the-Sun-Modells den vollen Betrieb der Plattform, über reines Monitoring hinaus. Mehr als 75 Milliarden US-Dollar jährlicher Bruttowarenwert laufen darüber, seit Jahren im Rahmen einer dauerhaften, laufenden Partnerschaft.

Fünf Kundenprojekte in Zahlen

Plattform zur Überprüfung von Anmeldeinformationen beziehungsweise Zertifikaten in regulierten Branchen: Deployments springen von zweimal im Monat auf mehrmals täglich, und 99 Prozent der Release-Schritte laufen automatisiert. Der Entwicklungsaufwand für das Release-Management sinkt außerdem um 30 Prozent, seitdem verfügbar für die Produktentwicklung.

DataFlow: Nach jedem Commit sinkt die Zeit bis zum Produktions-Deployment um den Faktor 5 auf wenige Minuten.

HomeToGo: mehr als 50 Produktions-Deployments pro Tag laufen bei 99,99 Prozent Verfügbarkeit, im laufenden Betrieb einer Plattform für Millionen Reisende.

roadsurfer: die technische Grundlage steht innerhalb von 20 Tagen produktionsreif, mit CI/CD-Disziplin von Beginn an.

Deutscher Fensterproduzent: Mit CI/CD- und DevOps-Praktiken als Teil einer Plattformüberholung senken wir die Ausfallzeiten und geben dem Unternehmen die volle Kontrolle über die eigene Technologie zurück.

Technologie, die sich in die bestehende Toolchain einfügt

Der Werkzeugkasten dafür umfasst GitHub Actions, GitLab CI, Jenkins, ArgoCD, Flux, Helm, Terraform, HashiCorp Vault, SonarQube, Trivy, Snyk, Prometheus, Grafana und Datadog. Er richtet sich nach der bestehenden Toolchain des Teams, die gewachsene Landschaft bleibt dabei erhalten.