GitOps klingt 2026 nicht mehr revolutionär. Trotzdem scheitern viele Teams beim Übergang — nicht weil das Konzept schwierig wäre, sondern weil die Einstiegshürden aus alten Gewohnheiten resultieren. kubectl apply ist schnell. Ein Pull Request gegen ein Gitops-Repo ist langsamer. Bis die Investition sich auszahlt, vergehen ein paar Wochen.
Das App-of-Apps-Pattern
Die eleganteste Art, ArgoCD zu strukturieren, ist das App-of-Apps-Pattern: Eine "Root-Application" verweist auf weitere ArgoCD-Applications, die wiederum die eigentlichen Helm-Charts deployen. Das ermöglicht hierarchische Organisation — Platform-Services, Tenant-Apps, Brand-spezifische Overlays — ohne dass man ein einziges Konfigurations-Monster pflegen muss.
Bei uns sieht das so aus: platform-app-of-apps enthält alle Infrastruktur-Services (cert-manager, ingress-nginx, postgresql, keycloak). sovaia-app-of-apps enthält alle tenant-spezifischen Services. Jedes Tenant-Team arbeitet in seinem Verzeichnis und sieht nur den eigenen Scope.
Sync Waves als Rettung
Ein häufiger Frust: Ein Service startet, bevor seine Abhängigkeiten bereit sind. Ingress-Nginx rollt aus, bevor cert-manager läuft → TLS schlägt fehl. Die Lösung ist die argocd.argoproj.io/sync-wave Annotation: Niedrigere Waves werden zuerst synchronisiert.
Wir haben uns auf folgende Konvention geeinigt:
- Wave 0: cert-manager
- Wave 1: coredns, external-secrets, ingress-nginx, cloudflared
- Wave 2: postgresql, redis, tenant-apps
- Wave 3: minio, monitoring, loki
- Wave 4: pgadmin, keycloak, velero
Wer neu dazukommt, schaut in diese Tabelle und weiß in dreißig Sekunden, wohin der neue Service gehört.
Image-Updates via Sha-Tags
Ein Entscheidungspunkt ist die Image-Tag-Strategie. Wir verwenden sha-<short>-Tags. Ein Commit in einem Service-Repo triggert einen CI-Build, der das Image mit dem Commit-Sha taggt. Anschließend updaten wir die values.yaml im gitops-Repo mit dem neuen Tag — das ist der eigentliche Deploy.
Warum nicht latest? Weil latest keine Reproduzierbarkeit bietet. Was heute als latest läuft, war vor einer Woche ein anderer Build. Rollbacks werden zu einem Rate-Spiel.
Warum nicht Semver? Weil es bei 20 Services zu viel Overhead ist. Sha-Tags sind uns automatisch richtig — jeder Commit ist ein eindeutiger Identifier, keine Meinungsbildung nötig.
Observability: Was wir wirklich brauchen
ArgoCD hat ein eigenes UI, das Sync-Status und Drift schön zeigt. In der Praxis reicht uns das für die tägliche Arbeit. Wenn etwas dramatischer schiefgeht, gehen wir zu Grafana — aber das ist seltener nötig, als man denkt.
Was wir gebaut haben: Ein Slack-Channel, der jeden erfolgreichen Sync und jeden Fehler postet. Das ersetzt keine echte Monitoring-Lösung, gibt aber allen Team-Mitgliedern einen asynchronen Überblick, ohne dass sie ArgoCD öffnen müssen.
Was wir heute anders machen würden
Wir haben am Anfang zu viel Zeit investiert, um alles zu parametrisieren. Drei Brands, vier Umgebungen, zwei Regionen — jede Achse als Helm-Values-Overlay. Das hat sich nicht ausgezahlt. Zwei Jahre später sind viele Parameter wieder hart kodiert, weil wir sie nie wirklich variiert haben.
Empfehlung: Erst variabilisieren, wenn der zweite oder dritte Fall auftaucht. Nicht auf Verdacht.