Veröffentlicht am: 1. Dezember 2025
7 Minuten Lesezeit
Wie wir die größte GitLab-Instanz 12-mal täglich bereitstellen
Systematische Deployment-Pipeline mit mehrstufigen Rollouts, Canary-Strategie (5% Traffic) und Datenbank-Migrationen für Millionen Entwickler(innen) weltweit.
GitLab führt täglich bis zu 12 Code-Bereitstellungen auf der weltweit größten GitLab-Instanz – GitLab.com – ohne Ausfallzeiten durch. Diese Bereitstellungen nutzen GitLabs eigene CI/CD-Plattform und betreffen Millionen Entwickler(innen) weltweit. Die hohe Bereitstellungsfrequenz dient als primäres Qualitätstor und Belastungstest. Organisationen, die auf GitLab für ihre DevOps-Workflows setzen, nutzen eine auf der eigenen Infrastruktur im Enterprise-Maßstab bewährte Plattform.
In regulierten Branchen wie dem Finanzwesen und der Automobilproduktion sind Zero-Downtime-Bereitstellungen keine Option, sondern Voraussetzung. Die NIS2-Richtlinie fordert in Artikel 21 systematische Risikoanalyse und Business-Continuity-Management – genau das, was GitLab.coms progressive Rollout-Strategie in der Praxis demonstriert. Durch mehrstufige Validierung mit isoliertem Canary-Traffic (5% aller Anfragen) werden potenzielle Probleme erkannt, bevor Millionen Nutzer(innen) betroffen sind.
Die Herausforderung: Frequenz trifft Skalierung
Für GitLab: Bereitstellungsfrequenz ist geschäftskritisch. Schnelle Deployment-Zyklen ermöglichen Reaktion auf Kundenfeedback innerhalb von Stunden, sofortige Security-Patches und Validierung neuer Features in Production vor Skalierung.
Für Kund(inn)en: Jede Bereitstellung auf GitLab.com validiert die Deployment-Praktiken, die GitLab seinen Nutzer(inne)n empfiehlt. Features werden auf der weltweit größten GitLab-Instanz getestet, bevor sie Kundenumgebungen erreichen. Dies liefert:
- Neueste Features sofort verfügbar (Stunden statt Wochen)
- Bewährte Zuverlässigkeit im Maßstab
- Zero-Downtime-Bereitstellungen garantieren durchgängigen Zugriff
- Dokumentation basiert auf tatsächlichen Production-Praktiken
Code-to-Production-Architektur
Die Deployment-Pipeline durchläuft strukturierte Phasen, wobei jede Phase als Checkpoint auf dem Weg zur Production-Bereitstellung fungiert:
graph TD
A[Code Proposed] --> B[Merge Request Created]
B --> C[Pipeline Triggered]
C --> D[Build & Test]
D --> E{Spec/Integration/QA Tests Pass?}
E -->|No| F[Feedback Loop]
F --> B
E -->|Yes| G[Merge to default branch]
G -->|Periodically| H[Auto-Deploy Branch]
subgraph "Deployment Pipeline"
H --> I[Package Creation]
I --> K[Canary Environment]
K --> L[QA Validation]
L --> M[Main Environment]
end
Progressive Rollout-Strategie
Build und Paket-Erstellung
GitLab erstellt sowohl Omnibus-Pakete als auch Cloud Native GitLab (CNG) Images. Omnibus-Pakete werden auf der Gitaly-Flotte bereitgestellt (Git-Storage-Layer), während CNG-Images alle anderen Komponenten als containerisierte Workloads ausführen. Eine geplante Pipeline sucht regelmäßig nach dem jüngsten Commit mit erfolgreicher Pipeline und erstellt daraus einen Auto-Deploy-Branch.
graph LR
A[Create branch] --> B[Build]
B --> C[Choose Built package]
C --> D[Start Deploy Pipeline]
Canary-Strategie und mehrstufige Validierung
GitLabs QA-Prozess arbeitet Hand in Hand mit der Canary-Strategie durch umgebungsbasierte Validierung. Etwa 5% des gesamten Traffics durchlaufen die Canary-Stage. Dieser Ansatz erhöht die Komplexität von Datenbankmigrationen, gewährleistet aber nahtlose Bereitstellung eines zuverlässigen Produkts.
Progressive Rollout-Phasen:
- Staging Canary: Initiale Validierungsumgebung
- Production Canary: Limitierter Production-Traffic
- Staging Main: Vollständige Staging-Umgebung
- Production Main: Vollständiger Production-Rollout
graph TD
C[Staging Canary Deploy]
C --> D[QA Smoke Main Stage Tests]
C --> E[QA Smoke Canary Stage Tests]
D --> F
E --> F{Tests Pass?}
F -->|Yes| G[Production Canary Deploy]
G --> S[QA Smoke Main Stage Tests]
G --> T[QA Smoke Canary Stage Tests]
F -->|No| H[Issue Creation]
H --> K[Fix & Backport]
K --> C
S --> M[Canary Traffic Monitoring]
T --> M[Canary Traffic Monitoring baking period]
M --> U[Production Safety Checks]
U --> N[Staging Main]
N --> V[Production Main]
QA-Validierung erfolgt an mehreren Checkpoints: nach jeder Canary-Bereitstellung und nach Post-Deploy-Migrationen. Weitere Details zur GitLab-Teststrategie finden sich im Handbook.
Deployment-Pipeline-Stages
GitLab.com repräsentiert reale Deployment-Komplexität im Maßstab. Als größte bekannte GitLab-Instanz nutzen Bereitstellungen denselben offiziellen GitLab Helm Chart und dasselbe Linux-Paket wie Kund(inn)en. Mehr zur GitLab.com-Architektur im Handbook.
Dogfooding im Maßstab: GitLab nutzt dieselben Verfahren, die für Zero-Downtime-Upgrades dokumentiert sind. Was bei GitLab nicht reibungslos funktioniert, wird Kund(inn)en nicht empfohlen.
Folgende Stages laufen für alle Environment- und Stage-Upgrades:
graph LR
a[prep] --> c[Regular Migrations - Canary stage only]
a --> f[Assets - Canary stage only]
c --> d[Gitaly]
d --> k8s
subgraph subGraph0["VM workloads"]
d["Gitaly"]
end
subgraph subGraph1["Kubernetes workloads"]
k8s["k8s"]
end
subgraph fleet["fleet"]
subGraph0
subGraph1
end
Stage-Details:
- Prep: Validiert Deployment-Bereitschaft und führt Pre-Deployment-Checks durch
- Migrations: Führt reguläre Datenbankmigrationen aus (nur Canary-Stage)
- Assets: Lädt statische Assets in GCS-Bucket hoch (nur Canary-Stage)
- Gitaly: Aktualisiert Gitaly-VM-Storage-Layer via Omnibus-Paket
- Kubernetes: Deployed containerisierte GitLab-Komponenten via Helm Chart
Multi-Version-Kompatibilität: Die versteckte Herausforderung
Während der Bereitstellung existiert eine Zeitspanne, in der das Datenbankschema dem Code voraus ist, den die Main-Stage kennt. Dies geschieht, weil die Canary-Stage bereits neuen Code deployed und reguläre Datenbankmigrationen ausführt, während die Main-Stage noch die vorherige Code-Version ausführt.
Beispiel: Bei Hinzufügen eines neuen merge_readiness-Felds zu Merge Requests laufen manche Server mit Code, der dieses Feld erwartet, während andere nichts davon wissen. Schlechte Handhabung würde GitLab.com für Millionen Nutzer(innen) unterbrechen. Gute Handhabung bleibt unbemerkt.
Mit wenigen Ausnahmen läuft die Mehrheit der Services für eine gewisse Zeit in leicht neuerer Version in Canary. Diese Szenarien sind transiente Zustände, können aber mehrere Stunden oder Tage in Live-Production-Umgebung persistieren. Daher müssen sie mit derselben Sorgfalt wie permanente Zustände behandelt werden.
Datenbank-Operationen
Datenbankmigrationen stellen eine besondere Herausforderung im Canary-Deployment-Modell dar. Schemaänderungen müssen neue Features unterstützen und gleichzeitig Rollback-Fähigkeit bewahren:
- Regular Migrations: Laufen während Canary-Stage, rückwärtskompatibel, nur reversible Änderungen
- Post-Deploy-Migrations: "Point of no Return"-Migrationen, die erst nach mehreren erfolgreichen Bereitstellungen laufen
graph LR
A[Regular Migrations] --> B[Canary Stage Deploy]
B --> C[Main Stage Deploy]
C --> D[Post Deploy Migrations]
Post-Deploy-Migrationen enthalten oft Änderungen, die nicht einfach rückgängig gemacht werden können – Datentransformationen, Column-Drops oder strukturelle Änderungen, die ältere Code-Versionen unterbrechen würden. Durch Ausführung nach Erlangung von Vertrauen durch mehrere erfolgreiche Bereitstellungen wird sichergestellt:
- Neuer Code ist stabil, Rollback unwahrscheinlich
- Performance-Charakteristiken in Production verstanden
- Edge Cases erkannt und adressiert
- Blast Radius minimiert, falls etwas schiefgeht
Dieser Ansatz bietet optimale Balance: schnelle Feature-Bereitstellung durch Canary-Releases bei gleichzeitiger Rollback-Fähigkeit bis Vertrauen in Deployment-Stabilität besteht.
Expand-Migrate-Contract-Pattern: Datenbank-, Frontend- und Anwendungskompatibilitäts-Änderungen folgen einem sorgfältig orchestrierten dreiphasigen Ansatz:
- Expand: Neue Strukturen hinzufügen, alte funktional belassen
- Migrate: Neuen Application-Code deployen, der neue Strukturen nutzt
- Contract: Alte Strukturen in Post-Deploy-Migrationen entfernen
Beispiel für merge_readiness-Column:
- Expand: Neue Column mit Default-Value hinzufügen; bestehender Code ignoriert sie
- Migrate: Code deployen, der neue Column liest und schreibt, alten Ansatz weiter unterstützt
- Contract: Nach mehreren erfolgreichen Bereitstellungen alte Column in Post-Deploy-Migration entfernen
Alle Datenbank-Operationen, Application-Code und Frontend-Code unterliegen Guidelines, dokumentiert in der Multi-Version-Compatibility-Dokumentation.
Ergebnisse und Auswirkungen
Für GitLab:
- Bis zu 12 Bereitstellungen täglich auf GitLab.com
- Zero-Downtime-Bereitstellungen für Millionen Entwickler(innen)
- Security-Patches erreichen Production innerhalb von Stunden
- Neue Features in Production im Maßstab validiert vor General Availability
Für Kunden:
- Bewährte Deployment-Patterns für eigene Anwendungen
- Features auf weltweit größter GitLab-Instanz getestet vor Erreichen der Kundenumgebung
- Dokumentation reflektiert tatsächliche Production-Praktiken
- Vertrauen, dass GitLabs empfohlene Upgrade-Prozeduren in jedem Maßstab funktionieren
Erkenntnisse für Engineering-Teams
Die hier beschriebenen Muster – von Expand-Migrate-Contract für Datenbankmigrationen bis zur Multi-Version-Kompatibilität – sind auf kleinere Deployments übertragbar. Nicht jede Organisation benötigt 12 Bereitstellungen täglich, aber die systematische Herangehensweise an Rollback-Fähigkeit und Validierungspunkte gilt unabhängig von der Skalierung.
GitLabs Deployment-Pipeline repräsentiert ein ausgereiftes System, das Deployment-Geschwindigkeit mit operationaler Zuverlässigkeit ausbalanciert. Das progressive Deployment-Modell, umfassende Testing-Integration und robuste Rollback-Fähigkeiten bieten Grundlage für zuverlässige Software-Auslieferung im Maßstab.
Zentrale Überlegungen für Engineering-Teams:
- Automatisiertes Testing: Umfassende Test-Coverage durch Deployment-Pipeline
- Progressive Rollouts: Gestufte Bereitstellungen zur Risikominimierung und schnellen Wiederherstellung
- Monitoring-Integration: Umfassende Observability über alle Deployment-Stages
- Incident Response: Schnelle Erkennungs- und Lösungsfähigkeiten für Deployment-Probleme
GitLabs Architektur demonstriert, wie moderne CI/CD-Systeme Komplexität großskaliger Bereitstellungen managen und gleichzeitig Geschwindigkeit für wettbewerbsfähige Software-Entwicklung bewahren.
Vollständige technische Dokumentation
Dieser Artikel beschreibt die Deployment-Patterns und systematische Herangehensweise für GitLab.com. Für vollständige Implementierungsdetails, spezifische Konfigurationsbeispiele und tiefergehende technische Architekturbeschreibungen siehe die englische Originalversion.
Weitere Dokumentation zu Auto-Deploy und Verfahren: