Von Staging-Stau zu Continuous Delivery: Wie ayedo für Vantara automatisierte Preview-Environments aufgebaut hat

Continuous Delivery ist kein Tool-Problem.
Es ist ein Feedback-Problem.

Vantara Digital entwickelt eine cloudbasierte Plattform für digitales Vertragsmanagement. Drei Feature-Teams arbeiten parallel an Frontend, Backend/API und Integrationen. Ziel der Geschäftsführung: wöchentliche Releases – perspektivisch Continuous Delivery.

Auf dem Papier war der Entwicklungsprozess sauber organisiert: Feature-Branches, Pull Requests, Code Reviews, Merge in den Hauptbranch, Deployment auf eine gemeinsame Staging-Umgebung. Ein klassisches Git-Flow-Modell.

In der Realität wurde genau dieses Modell zum Flaschenhals.

Ausgangslage: Eine Staging-Umgebung als zentraler Engpass

Alle Teams teilten sich eine einzige Staging-Umgebung. Jeder Pull Request musste dort deployt und getestet werden, bevor er gemergt werden durfte.

Was zunächst kontrolliert wirkt, erzeugte im Alltag massive Reibung.

Wenn Team A gerade einen größeren Datenbankumbau testete, konnten Team B und C ihre Features nicht parallel prüfen. Pull Requests stapelten sich in einer Merge-Queue. QA-Feedback verzögerte sich um zwei bis drei Tage. Entwickler wechselten in dieser Zeit den Kontext, Merge-Konflikte häuften sich und Code Reviews wurden auf veraltetem Stand durchgeführt.

Besonders problematisch war die späte Feedbackschleife. Tester konnten Features erst beurteilen, wenn sie auf Staging liefen. UX-Fehler oder konzeptionelle Schwächen wurden oft erst Tage nach der Implementierung sichtbar. Korrekturen waren entsprechend teuer – technisch wie mental.

Auch Product Owner und Stakeholder waren faktisch vom Entwicklungsprozess entkoppelt. Sie wollten Features früh sehen, mussten aber warten, bis sie auf Staging oder sogar in Production liefen.

In einzelnen Fällen bauten Entwickler manuell temporäre Umgebungen auf lokalen Maschinen oder einem Dev-Server, um Reviews zu ermöglichen. Diese Umgebungen waren nicht reproduzierbar, wichen vom Produktionssetup ab und verschwanden nach kurzer Zeit wieder.

Und dann war da noch das wiederkehrende Problem der „kaputten Staging-Umgebung". Ein fehlerhaftes Deployment konnte das gesamte System unbrauchbar machen. Das QA-Team stand still, bis jemand aus der Entwicklung Zeit fand, das Problem zu analysieren und zu beheben.

Das Resultat:
Statt wöchentlicher Releases schaffte Vantara faktisch nur alle zwei bis drei Wochen eine Veröffentlichung. Continuous Delivery blieb ein strategisches Ziel – aber operativ unerreichbar.

Der Wendepunkt: Feedback parallelisieren statt sequenziell verwalten

Für uns war schnell klar:
Das Problem war nicht QA.
Das Problem war geteilte Infrastruktur.

Wenn mehrere Teams parallel entwickeln, müssen sie auch parallel testen können. Eine einzige Staging-Umgebung zwingt sie in einen sequenziellen Prozess.

Die Lösung lag nicht in mehr Disziplin oder schnelleren Reviews, sondern in isolierten, automatisierten Preview-Umgebungen – pro Pull Request.

Die Lösung: Vollautomatisierte Preview-Environments auf ayedo Managed Kubernetes

Auf der ayedo Managed Kubernetes Plattform haben wir für Vantara ein GitOps-basiertes Preview-System aufgebaut.

Die Grundidee ist einfach – die Umsetzung sauber durchdacht:
Jeder Pull Request bekommt eine eigene, vollständige Umgebung. Automatisch.

GitLab CI als Trigger

Sobald ein Pull Request geöffnet wird, startet automatisch eine CI/CD-Pipeline. Diese Pipeline erzeugt ein deklaratives Manifest, das die komplette Umgebung beschreibt:

• Applikation mit dem Image des Feature-Branches
• eigene PostgreSQL-Datenbank mit Seed-Daten
• dedizierter Kubernetes Namespace
• Ingress mit individueller URL im Format pr-<nummer>.preview.vantara.dev

Dieses Manifest wird nicht direkt deployt – sondern in ein separates GitOps-Repository geschrieben.

ArgoCD als Deployment-Mechanismus

ArgoCD überwacht das GitOps-Repository. Sobald ein neues Manifest erscheint, rollt ArgoCD die vollständige Preview-Umgebung im Cluster aus.

Das geschieht innerhalb von rund 90 Sekunden – ohne manuelles Eingreifen.

Wird der Pull Request aktualisiert, erkennt ArgoCD die Änderung und aktualisiert die laufende Umgebung automatisch. Kein Neuaufsetzen, kein Warten, kein manuelles Re-Deploy.

Namespaces und Ressourcen-Isolation

Jede Preview-Umgebung läuft in einem eigenen Namespace mit definierten Resource Quotas. Kein Feature-Branch kann Ressourcen anderer Umgebungen blockieren.

Das bedeutet: Drei Teams können gleichzeitig jeweils fünf oder mehr Features parallel testen – auf produktionsnahen, identisch konfigurierten Umgebungen.

Automatisches Lifecycle-Management

Wird ein Pull Request gemergt oder geschlossen, entfernt die Pipeline das Manifest aus dem GitOps-Repository. ArgoCD löscht daraufhin automatisch die gesamte Umgebung.

Namespace, Datenbank, Ingress – alles wird sauber aufgeräumt.
Keine vergessenen Umgebungen, kein Wildwuchs.

Authentik für sicheren Zugriff

Alle Preview-Umgebungen sind über Authentik abgesichert. Entwickler, QA, Product Owner und Kundenberater authentifizieren sich mit ihren bestehenden Firmen-Credentials.

Bei Bedarf können temporäre Zugänge für externe Stakeholder erzeugt werden – mit begrenzter Laufzeit und klarer Zugriffskontrolle.

Der eigentliche Effekt: Feedback wird zum Echtzeit-Prozess

Der größte Unterschied war nicht technischer Natur – sondern organisatorisch.

Der neue Ablauf sieht heute so aus:

Ein Entwickler öffnet einen Pull Request.
90 Sekunden später steht eine vollständige, isolierte Umgebung bereit.
Die URL wird automatisch im Pull Request kommentiert.
QA, Product Owner und Stakeholder testen parallel.
Feedback fließt direkt in denselben PR zurück.
Nach dem Merge verschwindet die Umgebung automatisch.

Kein Deployment blockiert ein anderes.
Kein Team wartet auf Staging.
Kein Kontextwechsel durch tagelange Merge-Queues.

Der Entwicklungsprozess ist nicht länger sequenziell – sondern parallelisiert.

Ergebnis: Von zweiwöchigen Releases zu echter Delivery-Fähigkeit

Die durchschnittliche Zeit von „Feature fertig" bis „QA-Feedback" sank von mehreren Tagen auf unter vier Stunden.

Die gemeinsame Staging-Umgebung wird heute nur noch für finale Integrationstests genutzt. Sie bleibt stabil, weil der Großteil der Tests bereits isoliert in Preview-Umgebungen stattfindet.

Design- und UX-Fehler werden früh erkannt – solange sie noch klein und günstig korrigierbar sind.

Releases erfolgen inzwischen zuverlässig wöchentlich. Die Teams arbeiten bereits an einer weiteren Verkürzung der Zyklen.

Und ein oft unterschätzter Effekt:
„Works on my machine" existiert praktisch nicht mehr. Jede Preview-Umgebung ist identisch konfiguriert – gleiche Infrastruktur, gleiche Datenbank-Seeds, gleiche Policies wie in Production.

Continuous Delivery ist kein Ziel mehr auf einer Roadmap.
Es ist gelebte Praxis.

Warum dieser Ansatz funktioniert

Viele Unternehmen versuchen, Continuous Delivery durch strengere Prozesse zu erzwingen. In Wahrheit braucht es infrastrukturelle Parallelität.

Geteilte Testumgebungen erzeugen zwangsläufig Wartezeiten.
Isolierte, deklarative Umgebungen eliminieren sie.

GitOps sorgt dafür, dass jede Umgebung reproduzierbar, versioniert und automatisiert ausrollbar ist. Kubernetes liefert die Isolation. ArgoCD stellt Konsistenz sicher.

Das Ergebnis ist kein schnellerer QA-Prozess – sondern ein vollständig entkoppelter Entwicklungsfluss.

Call to Action

Wenn eure Teams auf eine gemeinsame Staging-Umgebung warten, ist das kein organisatorisches Problem – sondern ein Plattformthema.

Mit automatisierten Preview-Environments auf der ayedo Managed Kubernetes Plattform schaffen wir die Grundlage für echten Parallelbetrieb, frühes Stakeholder-Feedback und sichere, schnelle Releases.

Wenn ihr Continuous Delivery nicht nur als Vision, sondern als operativen Standard etablieren wollt, lasst uns sprechen. Wir analysieren euren aktuellen CI/CD- und QA-Prozess und zeigen euch, wie isolierte, GitOps-basierte Preview-Umgebungen euren Entwicklungsfluss nachhaltig beschleunigen können.

Wenn du möchtest, können wir diesen Case noch stärker auf „Developer Experience" zuspitzen oder SEO-seitig auf Keywords wie „Kubernetes Preview Environments", „GitOps QA Automatisierung" oder „Continuous Delivery mit ArgoCD" optimieren.