Praxis

Vom Merge Request zum Kundenrelease

So sieht kontrollierte Anwendungslieferung aus.

Benjamin Kötting 31. August 2026 Zuerst auf LinkedIn erschienen

Eine neue Funktion entsteht heute schnell. Durch Entwicklungsteams, durch KI oder durch beides.

Die entscheidende Frage beginnt danach: Wie wird aus einer Änderung ein Kundenrelease, den eine Agentur verantworten kann?

Dieses Beispiel zeigt einen vollständigen Ablauf an einem Kundenportal. Die neue Funktion: Kunden können einen bestehenden Termin direkt im Portal umbuchen, statt innerhalb von Öffnungszeiten anrufen zu müssen.

01 Die Änderung ist ein Merge Request, kein Direktzugriff auf Produktion

Die Änderung liegt in einem eigenen Branch. Eine Pflichtprüfung ist erfolgreich, aber die Auslieferung ist noch gesperrt: Es fehlt die Freigabe.

Merge Request mit erfolgreicher Pflichtprüfung, fehlender Freigabe und gesperrtem Merge-Knopf — Die Prüfung ist grün und als verpflichtend markiert. Darunter steht der Riegel: null von einer nötigen Freigabe. Der Merge-Knopf bleibt gesperrt.

Das ist der wichtige Unterschied zu automatisierter Bereitstellung: Die Änderung ist sichtbar, prüfbar und hat einen klaren Verantwortlichen.

02 Der Kunde sieht die Änderung, bevor sie live geht

In der Hauptumgebung gibt es bisher nur die Telefonnummer für Umbuchungen.

Kundenportal in der Hauptumgebung: Termin verschieben nur per Telefonnummer — Hauptumgebung: Umbuchen heißt anrufen, montags bis freitags von 8 bis 16 Uhr.

Für den Merge Request erzeugt die Platform automatisch eine getrennte Preview-Umgebung. Dort ist die neue Funktion mit echten, aber sicheren Testdaten im Browser sichtbar. Die Hauptumgebung bleibt unverändert.

Dieselbe Seite in der Preview-Umgebung, mit drei anklickbaren Terminvorschlägen und NEU-Marke — Preview-Umgebung zum selben Merge Request, unter eigener Adresse: die drei nächsten freien Termine sind direkt anklickbar. Die Telefonnummer bleibt.

ArgoCD macht die Trennung nachvollziehbar: Hauptanwendung und Preview laufen nebeneinander, jeweils gesund und synchron.

ArgoCD mit der Hauptanwendung und der Preview-Umgebung nebeneinander, beide gesund und synchron — Zwei getrennte Anwendungen, zwei getrennte Namensräume. Die Preview ist auf den Commit festgenagelt, nicht auf den Branch. Wird der Request geschlossen, verschwindet sie samt Umgebung wieder.

03 Erst nach Freigabe wird geliefert

Die Agentur prüft die sichtbare Änderung, gibt sie frei und mergt sie. Der Kunde behält die Entscheidung über seinen Release; die Agentur handelt im vereinbarten Betriebsrahmen.

Der Merge Request ist freigegeben und gemergt, mit sichtbarem Freigabevermerk und Merge-Commit — Freigabe und Merge stehen im Vorgang, mit Namen und Zeitpunkt. Der Merge-Commit ist benannt und damit später auffindbar.

Der Rollout passiert nicht über einen manuellen Serverzugriff. GitOps übernimmt die freigegebene Revision. ArgoCD dokumentiert, welche Revision wann ausgeliefert wurde und dass Anwendung und Ressourcen gesund sind.

ArgoCD zeigt die Kundenanwendung auf der neuen Revision, gesund und synchron, mit Zeitpunkt und Merge-Commit — Ausgeliefert. Die Anwendung steht auf der freigegebenen Revision, der auslösende Merge-Commit ist im Sync-Vermerk genannt.

04 Live ist nicht das Ende der Verantwortung

Die Anwendung wird im Normalbetrieb gemessen: Anfragen, Fehlerquote, Antwortzeit und bereite Pods.

Anwendungs-Dashboard im Normalbetrieb: Fehlerquote null Prozent, 404-Anteil getrennt ausgewiesen — Normalbetrieb. Die Fehlerquote zählt nur Serverfehler und steht auf null. Nicht gefundene Seiten stehen getrennt daneben, denn eine Anfrage nach etwas, das es nicht gibt, ist kein Ausfall.

Tritt ein Fehler auf, wird er sichtbar, bevor er zur bloßen Kundenmeldung wird.

Dasselbe Dashboard im Fehlerfall: Fehlerquote 100 Prozent in Rot, obwohl der Pod bereit ist — Derselbe Blick im Fehlerfall. Der Pod ist bereit, das Deployment gilt als gesund, und trotzdem gehen alle Antworten schief. Genau diese Lücke schließt die Messung an der Anwendung.

Der Alertmanager ordnet die Meldung dem richtigen Dienst zu. Die DevOps-KI kann dazu beraten und eine Handlungsempfehlung geben. Wirksame Maßnahmen bleiben eine Entscheidung der Agentur beziehungsweise des Kunden.

Alertmanager mit der aktiven Meldung, Dienstname, Schweregrad und Zeitpunkt — Die Meldung trägt den Dienst, den Schweregrad und den Zeitpunkt. Kein Rätselraten, welche Anwendung gemeint ist.

Nach der Behebung normalisiert sich die Anwendung, der Alert wird aufgehoben und der Ablauf bleibt nachvollziehbar.

Dashboard nach der Behebung: Fehlerquote wieder null, der Ausschlag bleibt in der Kurve sichtbar — Behoben. Die Fehlerquote steht wieder auf null, und der Ausschlag bleibt in der Kurve stehen. Was passiert ist, lässt sich später noch zeigen.

Was die Agentur damit verkauft

Nicht Kubernetes als Selbstzweck.

Sondern die Fähigkeit, Kundenanwendungen und später auch KI-Agenten schnell zu verändern, sichtbar zu prüfen, kontrolliert freizugeben und belastbar zu betreiben.

Das ist die Delivery Platform von koetting.io.

Erstgespräch vereinbaren Zur Agenturplattform