Von GitHub-Deployments zu Continuous Confidence: Wie ayedo eine Internal Developer Platform für Enterprise-Delivery aufgebaut hat

Viele Teams liefern heute containerisierte Software, nutzen GitHub, automatisieren Builds – und fühlen sich trotzdem nicht „plattformreif". Das liegt selten am Code. Es liegt daran, dass CI/CD als Pipeline-Logik verstanden wird, nicht als System. Solange Deployments direkt aus Build-Pipelines auf Serverzustände wirken, bleibt Delivery fragil: schwer reproduzierbar, schwer auditierbar, schwer zu betreiben.

In diesem Beitrag zeigen wir anhand eines anonymisierten Kundenprojekts, wie ayedo ein Softwarehaus mit starkem Projektgeschäft und wachsenden Enterprise-Anforderungen von einem GitHub-zentrierten Deployment-Modell auf eine moderne Internal Developer Platform (IDP) auf Managed Kubernetes geführt hat. Der Kunde bleibt anonym. Der Ansatz ist übertragbar – insbesondere für Organisationen, die Best-of-Breed Tooling nutzen wollen, aber endlich eine konsistente, revisionssichere Delivery- und Betriebsbasis brauchen.

Ausgangslage: Container ja – Plattform nein

Der Kunde entwickelt individuelle Softwarelösungen für Industrie, Energie und den öffentlichen Sektor und betreibt zusätzlich zwei eigene SaaS-Produkte. Rund 100 Mitarbeitende, etwa 40 Engineers, organisiert in acht Teams. Damit ist die Organisation groß genug, dass „jeder macht es ein bisschen anders" nicht mehr funktioniert – und klein genug, dass ein dediziertes Plattformteam nicht automatisch vorhanden ist.

Technisch war vieles bereits modern. Anwendungen waren containerisiert, Entwicklungsprozesse auf GitHub etabliert. Der gesamte Lifecycle stützte sich jedoch auf eine Struktur, die im Wachstum schnell brüchig wird: Mono-Repositories pro Kunde und Environment, GitHub Actions als zentraler Automatisierungsmechanismus und Deployments direkt aus Pipelines auf virtuelle Server, abgesichert durch selbstgehostete Action Runners.

Das funktioniert, solange die Komplexität überschaubar bleibt. Sobald mehrere Teams parallel ausrollen, mehrere Produkte und Kundenkontexte existieren und Enterprise-Kunden Prüf- und Nachweisfähigkeit verlangen, kippt das Modell.

Wo es weh tat: Pipeline als Single Point of Delivery

Die Probleme zeigten sich nicht in einem spektakulären Ausfall, sondern in Reibung – jeden Tag.

Deployments waren fehleranfällig, Pipelines brachen ab, manuelle Neustarts wurden Routine. Solange Delivery als Pipeline-Event verstanden wird, ist das normal: Jeder kleine Glitch in Runnern, Netzwerk oder Abhängigkeiten schlägt auf den Release-Prozess durch. Und weil Deployments direkt aus Pipelines auf Server wirken, ist ein Pipelinefehler nicht nur ein „Build-Problem", sondern ein potenziell inkonsistenter Zielzustand.

Gleichzeitig fehlte Observability. Es gab keine zentrale Sicht auf Logs, Metriken oder Traces. Damit war Betrieb reaktiv: Fehler wurden gesehen, wenn Nutzer sie meldeten – nicht, wenn sie entstehen. In einem Enterprise-Kontext ist das nicht nur ineffizient, sondern auch gefährlich, weil Nachweispflichten und Incident-Prozesse auf Daten basieren müssen.

Secrets wurden in GitHub-Repo-Variablen gepflegt. Auch wenn das pragmatisch ist, ist es in regulierten Umfeldern ein Risiko. Es fehlt die klare Trennung, wer wann welche Secrets genutzt hat, wie Rotation erfolgt und wie sich Zugriffe auditieren lassen.

Die Versionierung der Artefakte war zudem nicht konsistent. Wenn Container-Images nicht sauber versioniert und in nachgelagerte Repos propagiert werden, entstehen Kopplungen und manuelle Schritte. Genau diese manuellen Schritte sind es, die in Audits und in Incident-Analysen später schmerzhaft werden: „Welche Version läuft wirklich wo?"

Und schließlich war da das Compliance-Thema: Build und Deployment waren nicht getrennt, es gab keine revisionssichere Nachvollziehbarkeit entlang einer klaren Delivery-Kette, und der Betrieb hing stark am GitHub-Tooling-Kosmos. Mit neuen Enterprise-Kunden wurde deutlich: Unabhängigkeit vom Deployment-System ist nicht Luxus, sondern Voraussetzung.

Der Kern des Problems: fehlende Trennung zwischen Build, Deploy und Operate

In modernen Delivery-Modellen ist CI/CD nicht „eine Pipeline", sondern ein kontrollierter Prozess mit klaren Zuständigkeiten:

Build erzeugt ein Artefakt. Deploy setzt einen gewünschten Zustand durch. Operate überwacht, reagiert und liefert Nachweise.

Wenn diese drei Ebenen in einem Tool und einem Schritt verschmelzen, wird alles gleichzeitig komplexer: Compliance ist schwerer, Rollouts riskanter, Betrieb intransparent. Genau das war hier der Engpass.

ayedos Ansatz: Best-of-Breed Tooling auf Managed Kubernetes – als Internal Developer Platform

Wir haben die Aufgabe nicht als „Toolwechsel" verstanden, sondern als Aufbau einer internen Plattform, die Engineering-Teams entlastet und gleichzeitig Audit- und Betriebssicherheit erhöht.

Die ayedo Managed Kubernetes Plattform wurde zur Basis für eine Internal Developer Platform (IDP), die eine einheitliche CI/CD-Landschaft ermöglicht – mit klarer Trennung zwischen Build, Deployment und Betrieb und mit Komponenten, die sich als Standard in Enterprise-Umgebungen etabliert haben.

Wichtig war dabei ein Prinzip: Best-of-Breed Tooling, effizient integriert und fully managed. Das Ziel ist nicht, dass Teams mehr Tooling bedienen müssen, sondern dass die Plattform das Tooling so kapselt, dass Teams schneller liefern können – ohne Betrieb als Nebenjob.

GitOps mit ArgoCD: Deployment wird Zustand, nicht Event

ArgoCD wurde als zentrales Deployment-System eingeführt. Damit wechselt das Modell von „Pipeline pusht" zu „Cluster zieht". Deployments entstehen aus deklarativen IaC-Repositories, die den gewünschten Zustand beschreiben. ArgoCD reconciled diesen Zustand kontinuierlich.

Das ist nicht nur eleganter. Es löst mehrere Probleme gleichzeitig:

Die Delivery-Kette wird nachvollziehbar, weil jede Änderung im Git historisiert ist. Rollbacks werden kontrolliert, weil man auf bekannte Zustände zurückspringt. Und die Abhängigkeit vom Build-System sinkt, weil Build nicht mehr „auch deployt", sondern nur Artefakte produziert.

Observability als Plattformstandard: VictoriaMetrics, VictoriaLogs, Grafana und Tempo

Wir haben einen Full-Stack Observability-Ansatz etabliert, der Monitoring, Logging und Tracing abdeckt. VictoriaMetrics liefert skalierbare Metriken, VictoriaLogs zentralisiert Logs, Grafana macht Dashboards und Alerting konsumierbar, Tempo ergänzt die Tracing-Schicht.

Damit entsteht eine operative Realität, die vorher fehlte: Teams sehen nicht nur, ob etwas „läuft", sondern wie es läuft. Latenzen, Fehlerquoten, Sättigungen, Ausreißer – und vor allem der Zusammenhang zwischen Deployments und Verhalten im Betrieb. Das ist entscheidend, um Deployments häufiger zu machen, ohne Risiko zu erhöhen.

Supply-Chain-Security: Harbor mit CVE- und SBOM-Scanning

Ein wiederkehrender Enterprise-Blocker ist die Frage: „Welche Artefakte deployen wir, und wie stellen wir sicher, dass sie geprüft sind?" Hier haben wir Harbor als zentrale Container Registry integriert – inklusive CVE-Scanning und SBOM-Erzeugung.

Wichtig ist dabei der Übergang von „wir scannen irgendwann" zu „Scanning ist Gate". Wenn Artefakte in der Registry geprüft und klassifiziert werden, können Organisationen klare Regeln definieren, welche Risikostufen in welche Umgebungen dürfen. Damit wird Security Teil des Delivery-Prozesses, nicht ein nachgelagertes Projekt.

Identity und Zugriff: Keycloak für SSO und RBAC

Mit wachsender Team- und Kundenkomplexität wird Zugriff zum Compliance-Thema. Keycloak wurde als Identity Provider eingeführt, um SSO und rollenbasierte Zugriffe über Plattformkomponenten hinweg konsistent zu steuern.

Damit wird nicht nur Security besser. Es wird auch Betrieb effizienter, weil Zugriffe nicht in jeder einzelnen Anwendung separat „gebaut" werden müssen. In Audits ist das ein starkes Signal: klare Rollen, klare Verantwortlichkeiten, klarer Zugriffspfad.

Secrets Management: Vault statt Repo-Variablen

Die Migration auf Vault löst ein typisches Compliance- und Sicherheitsproblem: Secrets existieren nicht mehr als „Pipeline-Konfiguration", sondern als kontrolliertes, auditierbares System. Zugriff, Rotation und Policies werden zentral gesteuert.

Das hat direkte Auswirkungen auf Risiko und Geschwindigkeit. Teams verlieren weniger Zeit mit Secret-Wildwuchs, und gleichzeitig lässt sich gegenüber Kunden nachweisen, dass Secrets nicht unkontrolliert in Repos, Variablen oder Build-Logs auslaufen.

Build bleibt flexibel – Deployment wird standardisiert

Ein wichtiger Punkt war, dass Build-Pipelines nicht zwangsläufig ersetzt werden müssen. Viele Teams sind produktiv mit GitHub Actions – andere bevorzugen GitLab. Entscheidend ist nicht das Build-Tool, sondern die Schnittstelle: Build erzeugt versionierte Artefakte und aktualisiert Downstream IaC-Repositories automatisch.

In der Praxis bedeutet das: Commit-basierte Versionierung der Images, Push in Harbor, Update der Deployment-Definitionen in einem separaten IaC-Repo. Ab diesem Moment übernimmt ArgoCD. Dadurch wird aus „Pipeline als Allzweckwaffe" ein sauberer, entkoppelter Prozess.

Das reduziert Lock-in, weil Deployment nicht mehr von einem einzigen Tooling-Ökosystem abhängig ist. Und es erhöht die Auditierbarkeit, weil Build- und Deploy-Schritte getrennte, nachvollziehbare Spuren erzeugen.

Kubernetes-Mechaniken als Betriebsmotor: Self-Healing statt manueller Eingriffe

Die neue Plattform hat zudem Kubernetes-native Betriebsmechaniken konsequent genutzt: Liveness- und Readiness-Probes, Resource Requests und Limits, standardisierte Health Checks und automatisiertes Alerting.

Das ist nicht „Kubernetes-Basics". In der Praxis ist es der Unterschied zwischen Betrieb als Dauerintervention und Betrieb als kontrollierte Routine. Wenn Services sich selbst heilen und Überlastzustände früh sichtbar werden, sinkt die manuelle Eingriffshäufigkeit drastisch. Genau das war ein Ziel, weil ein Projekt- und Produktgeschäft parallel nur funktioniert, wenn Betrieb nicht ständig die Entwicklung ausbremst.

Ergebnis: Mehr Deployments pro Tag – mit Nachvollziehbarkeit statt Nervosität

Mit der Einführung der Internal Developer Platform wurde Delivery bei Codehaus deutlich schneller, ohne an Stabilität zu verlieren. Mehrere produktive Deployments pro Tag sind möglich, weil Rollouts kontrolliert, versioniert und beobachtbar sind.

Die Compliance-Fähigkeit stieg spürbar, weil Build, Deploy und Operate getrennt sind und jede Änderung revisionssicher nachvollziehbar wird. Secrets werden über Vault verwaltet, Artefakte über Harbor geprüft, und Observability liefert belastbare Daten für Betrieb und Nachweisführung.

Zugleich entstand echte Flexibilität: Deployments können in Cloud- und On-Premise-Umgebungen hinter Firewalls ausgerollt werden, ohne dass das Tooling neu gedacht werden muss. Das ist gerade für Enterprise-Kunden ein entscheidendes Argument – nicht weil On-Prem „besser" ist, sondern weil die Option in Ausschreibungen und Governance-Prozessen oft Voraussetzung ist.

Am Ende war der Sprung weniger „Continuous Delivery" als vielmehr „Continuous Confidence": häufiger liefern, mit weniger Risiko, mit mehr Beweisbarkeit.

Warum dieser Ansatz funktioniert: Plattformstandardisierung entkoppelt Geschwindigkeit von Risiko

Viele Organisationen versuchen, Compliance durch Prozessdokumente zu lösen. Das skaliert nicht. Was skaliert, ist ein Plattformmodell, das Nachweise automatisch erzeugt: Git-Historien für Changes, ArgoCD für Deployments, Harbor für Artefaktprüfungen, Vault für Secrets, Observability für Betriebsrealität.

Wenn diese Bausteine auf Managed Kubernetes integriert sind, entsteht Best-of-Breed ohne Tooling-Chaos. Und Teams gewinnen etwas, das in Enterprise-Projekten immer zählt: die Fähigkeit, schnell zu liefern und gleichzeitig regulatorisch belastbar zu sein.

Call to Action

Wenn eure CI/CD heute an GitHub Actions hängt, Deployments direkt aus Pipelines auf Server gehen, Secrets in Repo-Variablen liegen und Observability eher „später mal" ist, dann ist das kein Einzelfall – aber es ist ein Limit, das Enterprise-Kunden früher oder später erzwingen.

ayedo unterstützt beim Aufbau interner Developer Platforms auf Managed Kubernetes – mit GitOps über ArgoCD, Observability-Stacks, Supply-Chain-Security, zentralem IAM und Secrets Management. Damit Delivery nicht nur schneller wird, sondern belastbar.