Dein Coding-Agent ist keine Deployment-Pipeline

8 Min. Lesezeit

Die Korrektur ist live. Bestellen geht nicht mehr.

Aus der Abkürzung von gestern wird der Ablauf von heute

Eine Ladeninhaberin baut mit einem KI-Assistenten eine kleine Anwendung für Bestellungen. Sie kennt ihre Kunden und weiß, welche kniffligen Ausnahmen es in ihrem Geschäft gibt. Software in Betrieb zu nehmen ist neu für sie. Die erste Version läuft auf ihrem Laptop, also kopiert sie sie auf einen gemieteten Server. Kunden bestellen. Wunderbar.

Auch die nächste Änderung klappt. Bald bearbeitet der Assistent die Dateien direkt auf dem Server. Kopieren entfällt. Offenbar ein Fortschritt.

Dann ändert die Inhaberin die Versandkosten. Der Assistent stellt einen Teil der Anwendung auf ein neues Format um, während ein anderer noch das alte erwartet. Mitten in der Änderung will ein Kunde seine Bestellung abschließen. Der Warenkorb erscheint, doch der Kauf geht nicht durch. Die Inhaberin lädt die Startseite neu. Die funktioniert. Ihr Kollege versucht, tatsächlich etwas zu kaufen. Das klappt nicht.

Die Kunden konnten die Anwendung benutzen, während der Assistent sie noch änderte. Ob eine Bestellung durchging, hing vom Zeitpunkt und davon ab, ob alte und neue Teile zusammenarbeiten konnten. Beides hatte niemand geprüft.

Dem Agenten die Schuld zu geben, beruhigt. Der nächste Agent tappt damit in genau dieselbe Falle.

Jedes Release braucht eine eindeutige Kennung

Die erste Frage ist einfach. Was genau läuft da?

„Die Dateien auf dem Server“ bezeichnet einen Ort. Ein Release lässt sich damit nicht identifizieren. Wenn ein Teil gestern vom Laptop kam und der Rest bei der Reparatur heute Morgen dazukam, enthält das Verzeichnis womöglich eine Mischung, die es sonst nirgendwo je gegeben hat.

Lege den Quellcode und die Anweisungen für den Build in der Versionsverwaltung ab. Halte den Quellstand fest und erstelle daraus in einem wiederholbaren Ablauf ein Paket mit eindeutiger Versionskennung. Lege die Abhängigkeiten so fest, dass sich das beabsichtigte Ergebnis reproduzieren lässt. Halte umgebungsspezifische Einstellungen getrennt und lege Zugangsdaten in einem dafür vorgesehenen Speicher ab.

Ein solches Paket heißt oft Build-Artefakt. Das kann ein Container-Image sein, ein Anwendungsarchiv oder ein Paket mit statischen Dateien. Das Format hängt von der Anwendung ab. Entscheidend ist, dass sich das Paket eindeutig identifizieren lässt und beim Testen und beim Deployment unverändert bleibt.

DORA empfiehlt für automatisierte Deployments, in jeder Umgebung dieselben Pakete zu verwenden, die umgebungsspezifische Konfiguration getrennt zu halten und die Deployment-Skripte in die Versionsverwaltung aufzunehmen. So kannst du sicher sein, dass im Betrieb genau das Paket läuft, das die Prüfungen bestanden hat.

Wer für den Betrieb noch einmal baut, kann sich damit eine andere Abhängigkeit oder eine anders erzeugte Datei einhandeln. Wer das Paket nach den Tests ändert, hat das geänderte Paket noch nicht geprüft. Ein grüner Test gehört zu der Version, die ihn bestanden hat.

Besonders glamourös ist das alles nicht. Das ist einer seiner Vorzüge.

Die Startseite lädt. Versuch mal zu bestellen.

Für den Laden zählt, ob ein Kunde mit den richtigen Versandkosten bestellen kann und ob im Laden ein brauchbarer Auftrag ankommt. Weitere Prüfungen sollten fehlgeschlagene Zahlungen, mehrfach abgeschickte Bestellungen und die Zusagen der Anwendung zum Warenbestand abdecken.

Lass bei jeder Integration schnelle automatisierte Prüfungen laufen. Teste das fertige Paket in einer eigenen Testumgebung, bevor du es in Betrieb nimmst. Sie muss dem laufenden System ähnlich genug sein, damit die Fehler auffallen, auf die es ankommt. Verwende dafür Testkonten und geeignete Beispieldaten. Die privaten Daten sämtlicher Kunden braucht sie nicht.

Übe auch das Deployment selbst. Ein kleiner Shop kann das neue Paket neben dem alten installieren, den Start und die Verbindung zu den nötigen Diensten prüfen und dann die Anfragen auf die neue Version umleiten. Scheitert eine Prüfung, können die Kunden die alte Version weiter benutzen. Solange beide Versionen dieselbe Datenbank nutzen, müssen beide mit den Daten zurechtkommen.

Martin Fowler beschreibt eine Deployment-Pipeline als Folge von Stufen, auf denen weitere Prüfungen das Vertrauen in die Version erhöhen. Schnelle Rückmeldung kommt früh, aufwendigere Prüfungen folgen. An manchen Stellen kann ein Mensch bewusst über die Freigabe entscheiden. So lässt sich von der Änderung bis zur Freigabe nachvollziehen, welche Prüfungen das Release bestanden hat.

Bei Continuous Integration führen Entwickler ihre Änderungen häufig zusammen und prüfen das Ergebnis automatisch. Continuous Delivery hält die Software jederzeit bereit für ein Release. Die Inhaberin kann entscheiden, wann eine Änderung für ihre Kunden live geht. Wer jede Änderung nach bestandenen Prüfungen automatisch in Betrieb nimmt, betreibt Continuous Deployment.

Für eine winzige Anwendung können ein paar Prüfungen und ein kurzes Deployment-Skript genügen. Der Aufwand darf zum Laden passen. Den Bestellvorgang einer Bestellanwendung bei der Freigabe auszulassen, ist eine Leistung ganz eigener Art.

Der Rückweg muss mit den heutigen Daten funktionieren

Halte die letzte nachweislich funktionierende Version bereit und kläre, wie du zu ihr zurückwechselst. Übe den Wechsel, bevor du ihn für einen brauchbaren Notfallplan hältst. Prüfe den Dienst auch nach dem Umschalten. Ein laufender Prozess kann immer noch jeden Kauf scheitern lassen.

Jetzt wird es unbequem. Angenommen, die neue Version speichert die Versandkosten anders. Die alte Version versteht womöglich die Bestellungen nicht, die seit der Umstellung eingegangen sind. Der Wechsel zum alten Paket könnte einen Fehler durch einen anderen ersetzen.

Plane Datenbankänderungen möglichst so, dass alte und neue Anwendungsversionen während der Umstellung nebeneinander laufen können. Ein neues Feld hinzuzufügen, die Nutzung nach und nach umzustellen und das alte Feld später zu entfernen, lässt sich im Fehlerfall oft leichter auffangen als ein Austausch in einem Schritt. Manche Änderungen erfordern trotzdem eine gezielte Korrektur an der neuen Version oder ein sorgfältig geplantes Wiederherstellungsverfahren.

Ein Backup hilft bei Datenverlust. Wer es einspielt, verliert unter Umständen gültige Bestellungen, die seit der Sicherung eingegangen sind. Eine beim Zahlungsdienstleister schon ausgelöste Erstattung verschwindet nicht höflich, nur weil jemand die Datenbank zurückgesetzt hat. Der Notfallplan muss auch solche Vorgänge außerhalb des Shops berücksichtigen.

Für die Inhaberin geht es um eine Frage, für die sie keine Fachbegriffe lernen muss. Wenn der neue Bestellvorgang nach drei erfolgreichen Käufen ausfällt, können wir den Betrieb wiederherstellen und diese Bestellungen samt Zahlungsdaten behalten?

Die Frage stellt man besser, bevor der vierte Kunde den Versuch übernimmt.

Der Assistent sollte den fehlenden Schritt erklären

Auf die Bitte „Stell meine App online“ sollte der Assistent zuerst klären, was die App tun und wo sie laufen soll. Ist es eine Demo zum Wegwerfen, ein internes Werkzeug oder ein Dienst, der Geld von Kunden annimmt? Wie gehen Änderungen bisher live? Wer ist für die Daten im laufenden Betrieb verantwortlich? Was darf der Assistent ändern?

Dann sollte er konkret werden. Änderung festhalten, die nötigen Prüfungen ausführen, ein Paket mit eindeutiger Versionskennung bauen, das Deployment in der passenden Umgebung erproben und den Rückweg klären, bevor die neue Version live geht. Hat das Projekt bereits einen Startbefehl und einen Ablauf für Deployments, soll er sie nutzen. Einen zweiten Weg zu schaffen, weil das einen Prompt spart, ist eine eigenwillige Vorstellung von Effizienz.

Ein Agent kann beim Aufbau und bei der Durchführung dieses Ablaufs helfen. Er kann eine fehlgeschlagene Prüfung untersuchen, das Deployment-Skript verbessern oder ein genehmigtes Deployment auslösen. Der Ablauf darf nicht nur in seiner Sitzung stehen. Konfiguration und Prüfergebnisse müssen nach dem Gespräch noch auffindbar sein.

Der Deployment-Job bekommt die Rechte, die er braucht, um ein freigegebenes Paket zu installieren und die live geschaltete Version zu protokollieren. Der Assistent kann Code mit eigenen, getrennten Rechten bearbeiten und testen.

Notreparaturen können Ausnahmen erfordern. Halte fest, was sich geändert hat, übernimm die Korrektur in den regulären Quellcode und stelle anschließend wieder einen bekannten Release-Stand her. Sonst wird die Ausnahme still und leise zum Deployment-Verfahren von morgen.

Leicht zu bauen heißt noch lange nicht leicht zu betreiben

Lange bevor man im Dialog programmieren konnte, entstanden nützliche Anwendungen für einzelne Abteilungen mit Visual Basic, Tabellen und Makros. Aus einem hilfreichen Werkzeug konnte etwas werden, auf das sich Kollegen täglich verließen. Sein Ersteller bekam dadurch nicht plötzlich Erfahrung mit Tests, Releases, Zugriffsrechten und Wiederherstellung. Mit KI kann der Weg von der Idee zu dieser Verantwortung kürzer werden.

Auf einer gehosteten Plattform kann der Anbieter einen großen Teil der Arbeit rund um Releases übernehmen. Dafür zu bezahlen kann sinnvoll sein. Der Anbieter betreibt die Plattform, und der Nutzer arbeitet innerhalb der Möglichkeiten, die sie unterstützt. Prüfe, wo diese Grenzen liegen, besonders wenn Kundendaten und externe Dienste ins Spiel kommen.

Wer den Code auf einen eigenen Server legt, muss plötzlich selbst Fragen zum Betrieb beantworten. Dass man anderswo auf „Teilen“ klicken konnte, beantwortet keine davon. Der Enthusiasmus des Assistenten auch nicht.

Für diese Lücke braucht es keinen geheimen Plan der Anbieter. Eine schnelle Demo lässt sich leicht zeigen. Ein verlässliches zweites Release ist in einem Werbevideo schwerer unterzubringen.

Die Inhaberin verdient beides. Aus einem nützlichen Experiment einen verlässlichen Service zu machen heißt auch, Änderungen so alltäglich zu machen, dass ihr Kollege währenddessen weiter Bestellungen packen kann.

Wenn sie den Assistenten das nächste Mal bittet, die Versandkosten zu korrigieren, braucht sie eine vollständige Version zum Testen, einen bekannten Weg in den Betrieb und eine glaubwürdige Antwort für den Fall, dass etwas schiefläuft. Die Kunden haben genug zu bedenken, wenn sie sehen, was der Versand kostet.