Keine Umgebungskonflikte mehr: Wie E-Pods jedem Entwickler bei SnapLogic einen eigenen Produktionsklon zur Verfügung stellt

Entwicklungsteams stehen vor einer entscheidenden Herausforderung: Wie lassen sich Funktionen in produktionsnahen Umgebungen testen, ohne die Stabilität zu beeinträchtigen, die Kosten in die Höhe zu treiben oder andere Entwickler auszubremsen? Das herkömmliche Modell einer gemeinsam genutzten Staging-Umgebung verursacht Engpässe, führt zu Instabilität und verlangsamt die Bereitstellungsgeschwindigkeit. Gleichzeitig ist es unerschwinglich teuer und betrieblich komplex, für jeden Entwickler komplette Infrastrukturklone einzurichten.

Um dieses Problem zu lösen, haben wir E-Pods (Ephemeral Pods) entwickelt: ein GitOps-basiertes Framework, das Entwicklern über einen einfachen Pull-Request-Workflow bedarfsgerechte, isolierte und produktionsähnliche Umgebungen bereitstellt. In diesem Beitrag wird erläutert, wie E-Pods kosten- und risikobewusste Entwicklungspraktiken ermöglichen und gleichzeitig Innovationen beschleunigen.

Das Problem der gemeinsam genutzten Umgebung

Jedes IT-Unternehmen, das über eine Handvoll Entwickler hinausgewachsen ist, kennt die Probleme, die mit gemeinsam genutzten Staging-Umgebungen einhergehen. Der Konflikt ist grundlegender Natur: Entwickler benötigen Stabilität, um ihre Änderungen zu testen, müssen aber gleichzeitig potenziell instabilen Code bereitstellen, um diese Änderungen zu validieren. Wenn sich mehrere Teams dieselbe Umgebung teilen, entsteht Chaos.

Stellen Sie sich folgendes Szenario vor: Team A führt eine Änderung ein, die Kompatibilitätsprobleme verursacht, um eine neue Funktion zu testen. Gleichzeitig versucht Team B, den Stakeholdern seine Arbeit vorzustellen. Die Überprüfung einer kritischen Fehlerbehebung durch Team C ist nun blockiert, da die Umgebung instabil ist. Kommt Ihnen das bekannt vor?

Die herkömmlichen Lösungen weisen alle Nachteile auf:

• Gemeinsam genutzte Staging-Umgebungen: Sie führen zu Engpässen, Instabilität und gegenseitigen Schuldzuweisungen, wenn etwas nicht funktioniert
• Langlebige Entwicklungsumgebungen: Sie sammeln Abweichungen an, werden kostspielig und verursachen dennoch Planungs-Konflikte
• Vollständige Infrastrukturklone: Bei großem Umfang unerschwinglich und betrieblich komplex
• Nur für die lokale Entwicklung: Nicht ausreichend für das Testen von Integrationen, der Interaktion zwischen Microservices und infrastrukturabhängigen Funktionen

Wir stellen vor: E-Pods – durch GitOps gesteuerte temporäre Umgebungen

E-Pods verfolgen einen anderen Ansatz. Anstatt komplexe Workflows zur Bereitstellung von Umgebungen zu verwalten oder die Bereitstellung über mehrere Tools hinweg durchzuführen, öffnen Entwickler einfach einen GitHub-Pull-Request. Das ist alles. Das Framework kümmert sich um alles Weitere: die Bereitstellung der Infrastruktur, die Bereitstellung von Diensten, die Konfiguration des Netzwerks und die Bereitstellung von Zugangsdaten.

So funktionieren E-Pods

Der Arbeitsablauf bei E-Pods ist elegant einfach:

1. Erstellen Sie einen Pull-Request. Entwickler erstellen einen PR in unserem dafür vorgesehenen E-Pods-Repository und geben dabei an, welche Dienste sie benötigen und welche Versionen sie wünschen. Der PR dient als zentrale Referenz für die Konfiguration der Umgebung.

2. Zusammenführen und bereitstellen. Sobald der PR zusammengeführt wurde, erkennt unser GitOps-Controller (basierend auf ArgoCD) die Änderung und beginnt mit der Bereitstellung. Die Schritte:

• Erstellt isolierte Kubernetes-Namespaces
• Stellt die angegebenen Dienstversionen bereit
• Konfiguriert Netzwerk- und Service-Mesh-Regeln
• Richtet Überwachung und Observability ein
• Bereitstellung von temporären Datenbanken

3. Anmeldeinformationen für die Umgebung erhalten Innerhalb weniger Minuten erhalten Entwickler eine E-Mail mit folgenden Inhalten:

• URLs für den Zugriff auf die Umgebung
• Anmeldedaten für die Benutzeroberfläche

4. Überwachung über Slack: In Slack werden Statusaktualisierungen in Echtzeit angezeigt, sodass die Entwickler stets über Folgendes informiert sind:

• Fortschritt der Bereitstellung
• Zustandsprüfungen für Dienste
• Umgebungsvorbereitung

5. Versionsverwaltung mit Kargo Hier spielen E-Pods ihre wahren Stärken aus. Wir haben Kargo integriert, ein Continuous-Delivery-Tool, das eine visuelle Oberfläche für die Versionsverwaltung bietet. Entwickler greifen auf eine spezielle Kargo-URL zu, über die sie:

• Alle verfügbaren Serviceversionen im „Warehouse“ anzeigen
• Serviceversionen mit einem einzigen Klick aktualisieren oder auf eine niedrigere Version zurücksetzen
• Verfolgung der Werbephasen über verschiedene Dienste hinweg
• Den Bereitstellungsverlauf anzeigen und bei Bedarf zurücksetzen

Kargo synchronisiert sich mit unserem CI-System (in unserem Fall Travis CI) und ruft automatisch neu erstellte Container-Images ab. Sobald der Build eines neuen Feature-Branches abgeschlossen ist, wird dieser den Entwicklern sofort in ihrer E-Pods-Kargo-Oberfläche angezeigt.

6. Automatische Bereinigung: E-Pods sind von Grund auf auf Kosteneffizienz ausgelegt. Jede Umgebung hat eine festgelegte Lebensdauer. Vor dem Herunterfahren:

• Entwickler erhalten eine E-Mail-Benachrichtigung, in der sie vor der bevorstehenden Löschung gewarnt werden
• Sie können die Lebensdauer der Anlage verlängern
• Oder lösche es manuell über einen GitHub-PR, sobald die Tests abgeschlossen sind

Der Vorteil von GitOps

Unsere gewählte Implementierungsmethode, GitOps, bietet mehrere sich gegenseitig verstärkende Vorteile.

Deklarative Konfiguration. Umgebungsdefinitionen werden in Git gespeichert und bieten:

• Versionshistorie und Prüfpfade
• Einfaches Zurücksetzen auf frühere Konfigurationen
• Peer-Review im Rahmen von PR-Workflows
• Dokumentation, die nicht von der Realität abweichen darf

Selbstbedienung ohne Komplexität. Entwickler müssen sich nicht mit Kubernetes, Helm-Charts oder Infrastructure as Code auskennen. Sie arbeiten mit vertrauten Git-Workflows und YAML-Konfigurationsdateien.

Abgleich und Abweichungserkennung. Der GitOps-Controller gleicht den Sollzustand (in Git) kontinuierlich mit dem Istzustand (im Cluster) ab. Wenn jemand einen E-Pod manuell ändert, korrigiert der Controller dies automatisch.

Integration in bestehende Arbeitsabläufe. Da Entwicklungsteams GitHub bereits für die Codeüberprüfung nutzen, entsteht durch die Einbindung der Umgebungsbereitstellung in denselben Arbeitsablauf keinerlei zusätzlicher kognitiver Aufwand.

Auswirkungen in der Praxis: Die Transformation der Entwicklererfahrung

Seit der Einführung der E-Pods konnten wir in verschiedenen Bereichen deutliche Verbesserungen feststellen:

Geschwindigkeitssteigerungen

Vor den E-Pods:

• Durchschnittliche Dauer bis zur Bereitstellung einer Testumgebung: 2–3 Tage (einschließlich Beantragung, Einrichtung und Wartezeit bis zur Verfügbarkeit der gemeinsam genutzten Umgebung)
• Umgebungskonflikte: 3–5 pro Woche, die manuell behoben werden müssen
• Fehlgeschlagene Bereitstellungen aufgrund einer instabilen Umgebung: ~30 % der ersten Versuche

Nach den E-Pods:

• Durchschnittliche Zeit bis zur Bereitstellung einer Testumgebung: 3–5 Minuten (vom Zusammenführen des Pull-Requests bis zur Betriebsbereitschaft)
• Umgebungskonflikte: Null (vollständige Isolation)
• Failed deployments due to environment issues: <5%

Kosteneffizienz

Durch die Einführung einer automatischen Bereinigung und einer bedarfsgerechten Ressourcenzuweisung haben wir Folgendes erreicht:

• Senkung der Kosten für die Entwicklungsinfrastruktur
• Senkung des Ressourcenverbrauchs im Leerlauf
• Beseitigung langlebiger, in Vergessenheit geratener Entwicklungsumgebungen

Zufriedenheit der Entwickler

Das qualitative Feedback war durchweg positiv:

• Entwickler geben an, weniger Zeit für die Verwaltung der Entwicklungsumgebung und mehr Zeit für das Programmieren aufzuwenden
• Weniger Reibungsverluste bei der teamübergreifenden Zusammenarbeit (keine Terminkonflikte mehr)
• Schnellere Funktionsvalidierung und Präsentationen für Stakeholder
• Geringere Angst vor der Beschädigung gemeinsamer Umgebungen

Flüchtige Umgebungen als Wettbewerbsvorteil

Im Wettlauf um schnellere Innovationszyklen und eine zuverlässigere Softwarebereitstellung sind kurzlebige Umgebungen zu einer Wettbewerbsnotwendigkeit geworden. E-Pods zeigt, dass Unternehmen mit den richtigen architektonischen Entscheidungen, GitOps, Kostenbewusstsein, Risikoisolierung und entwicklerorientierten Arbeitsabläufen ihren Entwicklern leistungsstarke Testfunktionen zur Verfügung stellen können, ohne dass dabei hohe Kosten entstehen oder der Betrieb komplexer wird.

Die Zukunft der Entwicklungsumgebungen ist kurzlebig, isoliert und bedarfsorientiert. Indem E-Pods die Bereitstellung von Umgebungen als Code behandelt, sich in bestehende Entwickler-Workflows integriert und Kostenbewusstsein von Grund auf einbaut, ermöglicht es unseren Teams, schneller voranzukommen und gleichzeitig die Stabilität und Zuverlässigkeit zu gewährleisten, die unser Unternehmen benötigt.