Deployment-Prozesse mittels Custom Agent in GitLab Duo Agent automatisieren

Jedes Engineering-Team kennt diese Aufgaben: komplex, repetitiv und zeitaufwändig – aber absolut kritisch, um sie richtig auszuführen. Das Onboarding eines neuen Microservices in einen etablierten GitOps-Deployment-Workflow ist ein gutes Beispiel. Es umfasst das Generieren maßgeschneiderter Manifeste, das Aktualisieren von Delivery-Pipelines, das Konfigurieren der Image-Automatisierung und die Sicherstellung, dass jedes Element auf die richtigen Namespaces, Ports und Hostnamen verweist. Wird ein Schritt übersprungen, schlägt das Deployment fehl. Manuell ausgeführt kann ein solches Setup Stunden kosten – manchmal einen ganzen Tag –, obwohl es jedes Mal demselben Muster folgt.

Das ist genau die Art von Arbeit, für die KI-Agenten gebaut wurden. Mit der GitLab Duo Agent Platform lässt sich ein Custom Agent erstellen, der die spezifische Anwendung, den spezifischen GitOps-Workflow und die spezifischen Konventionen versteht – und das komplexe Onboarding dann selbst durchführt. Noch besser: Der Agent selbst sowie alle von ihm generierten Artefakte sind in GitLab versioniert, verwaltet und kontrolliert. So entsteht die Geschwindigkeit der Automatisierung, ohne auf Enterprise-Kontrolle verzichten zu müssen.

In diesem Tutorial wird gezeigt, wie ein solcher Custom Agent von Grund auf aufgebaut wird – vom Generieren des System Prompts bis hin zum neuen Microservice, der auf einem Kubernetes-Cluster läuft. Der folgende Inhalt begleitet das Tutorial:

Anwendungsfall: Onboarding eines Microservices für TanukiBank

Als konkretes Beispiel dient eine fiktive Bank namens TanukiBank. Die Web-Anwendung der Bank bietet Girokonten, Sparkonten, Wohnungsbaukredite, Rechner für Hypotheken und Autokredite sowie eine Seite für Zahlungen und Überweisungen. Diese Seite enthält ein Quick-Transfer-Panel mit dem Ziel, Überweisungen zwischen Konten zu ermöglichen. Das Panel ist derzeit nicht implementiert – beim Klick auf „Überweisung" passiert nichts, da der zugrundeliegende Microservice noch nicht existiert. Die Aufgabe besteht darin, diesen Microservice zu bauen und ihn mit einem Custom Agent in TanukiBanks bestehenden GitOps-Workflow einzubinden.

Die Anwendung und der GitOps-Prozess

TanukiBanks Code lebt in einer GitLab-Group mit einer services-Subgroup, die jeden Microservice enthält (Home-Mortgage- Rechner, Auto-Loan-Rechner usw.), sowie zwei Top-Level-Projekten – Tanuki Bank - Delivery und Flux Config –, die das Deployment auf einem Kubernetes-Cluster steuern.

Der GitOps-Workflow funktioniert so: Jeder Microservice hat eine Pipeline, die ein Container-Image baut und es in die integrierte Container-Registry pusht. Der Flux Image Automation Controller, der auf dem Kubernetes-Cluster läuft, überwacht diese Registries auf Änderungen und aktualisiert bei Erkennung einer Änderung das entsprechende Manifest im Projekt Tanuki Bank - Delivery. Das löst eine Delivery-Pipeline aus, die ein neues Container-Image baut und signiert und es in der Registry des Delivery-Projekts speichert. Schließlich hält der Flux CD Controller die laufenden Pods im Kubernetes-Cluster über alle Umgebungen hinweg synchron mit der Container-Registry des Delivery-Projekts. Alle Flux-Manifeste leben im Projekt Flux Config.

Das ist ein sauberer Workflow – aber das Onboarding jedes neuen Microservices bedeutet, alle diese beweglichen Teile auf genau die richtige Weise anzufassen. Ein Custom Agent, der dieses Onboarding übernimmt, vereinfacht das erheblich.

Den System Prompt generieren

Ein Custom Agent ist nur so gut wie sein System Prompt. Statt ihn von Grund auf zu schreiben, übernimmt GitLab Duo die Hauptarbeit. Aus der tanukibank-Group heraus wird GitLab Agentic Chat geöffnet und darum gebeten, die Group, ihre Subgroups und deren Inhalte zu untersuchen und dann einen System Prompt für einen Agenten zu entwerfen, der neue Microservices onboarden kann. Im Wesentlichen wird Duo gebeten, den etablierten GitOps-Workflow der Anwendung gründlich zu verstehen und zu lernen – damit Duo einen System Prompt erstellen kann, der genug Detail enthält, um das Onboarding eines neuen Microservices in diesen GitOps-Workflow zu automatisieren.

GitLab Duo liest die Dateien, untersucht die Manifeste und Konfigurationsdateien, analysiert die Dockerfiles, kartiert Abhängigkeiten und erstellt dann einen detaillierten System Prompt mit Berichtsanweisungen, einzuhaltenden Regeln und empfohlenen zu aktivierenden Werkzeugen. Diese Ausgabe wird für den nächsten Schritt gespeichert.

Ein wichtiger Hinweis: Der von GitLab Duo generierte System Prompt ist spezifisch für den GitOps-Workflow dieser Anwendung zum jetzigen Zeitpunkt. Sollte sich der GitOps-Workflow künftig ändern, muss dieser System Prompt durch erneutes Ausführen dieses Schritts neu generiert werden.

Den Custom Agent erstellen

Als Nächstes wird ein neues leeres Projekt namens application-agents erstellt. Dieses Projekt verwaltet die Custom Agents – einschließlich der Frage, wer sie administrieren kann und wo sie ausgeführt werden dürfen. Dafür werden folgende Schritte ausgeführt:

1. Unter AI > Agents den Tab Managed auswählen.
2. Auf New agent klicken, um einen neuen Agenten namens TanukiBank Microservice Onboarder zu erstellen, eine kurze Beschreibung hinzuzufügen und ihn als öffentlich kennzeichnen.
3. Die von GitLab Duo empfohlenen Werkzeuge auswählen.
4. Den generierten System Prompt einfügen.
5. Den Agenten erstellen.

Sobald der Agent erstellt ist, wird er in beiden Projekten aktiviert, die den GitOps-Workflow steuern: Tanuki Bank - Delivery und Flux Config. Das Agentic-Chat-Panel in jedem Projekt öffnen und bestätigen, dass TanukiBank Microservice Onboarder im Agenten-Dropdown erscheint, verifiziert die Einrichtung.

Mit dem Developer Flow einen neuen Microservice erstellen

Vor dem Testen des Agenten wird ein tatsächlicher Microservice zum Onboarden benötigt. Dafür wird zur services-Group navigiert, ein neues Projekt namens intra-account-transfers erstellt und der Developer-Foundational-Flow der GitLab Duo Agent Platform eingesetzt.

Ein neues Issue wird im Projekt geöffnet, und in seiner Beschreibung werden Spezifikationen für den Microservice aufgelistet. Dann wird die Schaltfläche Generate MR with Duo geklickt, die den Developer Flow startet. Der Agent liest die Spezifikation, implementiert den Microservice, erstellt einen Branch und einen Merge Request und verknüpft den MR mit dem Issue. Nach der Überprüfung, dass die Implementierung lokal mit einem schnellen curl-Befehl funktioniert, wird der MR gemergt. Die Pipeline läuft und pusht die neuen Container-Images in die Registry des Projekts.

Zu diesem Zeitpunkt existiert der neue Microservice, aber der umfassendere GitOps-Workflow weiß noch nichts davon. Das manifests/dev-Verzeichnis im Projekt Tanuki Bank - Delivery enthält nichts für intra-account-transfers, die Delivery-Pipeline referenziert ihn nicht, und die Datei image-update-automation.yaml im Projekt Flux Config hat keine Einträge für den neuen Microservice.

Den Custom Agent einsetzen

Nach der Aktivierung des TanukiBank Microservice Onboarder im neu erstellten Projekt intra-account-transfers wird zu Tanuki Bank - Delivery navigiert, das Agentic-Chat-Panel geöffnet, der Custom Agent aus dem Agenten-Dropdown gewählt und er darum gebeten, den neuen Service zu onboarden – unter Angabe des Service-Namens und Hostnamens.

Der Agent macht sich an die Arbeit. Er lokalisiert und liest das Dockerfile des neuen Microservices, um seinen Port zu ermitteln, generiert die entsprechenden Manifeste und aktualisiert die relevanten Pipelines. Unterwegs fragt er um Genehmigung, bevor er Commits und Merge Requests erstellt – die erteilt werden.

Dann öffnet der Agent zwei MRs – einen in Tanuki Bank - Delivery und einen in Flux Config – und schließt mit einer Zusammenfassung von allem, was er getan hat: Links zu den MRs, Service-Details, erstellte und geänderte Dateien sowie empfohlene nächste Schritte.

Die Ergebnisse

Die Änderungen in beiden MRs werden überprüft, zunächst der Flux Config-MR gemergt, um die Flux-Komponenten zu aktualisieren, dann der MR von Tanuki Bank - Delivery. Zur Überprüfung des Deployments wird in GitLab eine neue Umgebung namens intra-account-transfers-dev erstellt, die mit dem Kubernetes-Cluster verbunden ist, der entsprechende Namespace und die Flux-Ressource ausgewählt und gespeichert.

Die Umgebungsansicht zeigt die frisch gestarteten Pods, und ein kubectl-Listing im Terminal bestätigt drei neue laufende Pods. Ein abschließendes curl gegen den öffentlichen Hostnamen itransfers2.ocpgitlab.com liefert die korrekte Antwort. Der Microservice ist live – und das Onboarding, das manuell potenziell Stunden sorgfältiger Arbeit gekostet hätte, dauerte Minuten.

Vorteile

Ein Custom Agent auf der GitLab Duo Agent Platform bietet Mehrwert auf mehreren Ebenen. Er komprimiert komplexe Multi-Projekt-Setup-Arbeit auf Minuten und gibt Engineers die Freiheit, sich auf höherwertige Probleme zu konzentrieren. Er erfasst organisationales Wissen und Kontext – die spezifischen GitOps-Konventionen, Benennungsmuster und Pipeline-Strukturen – als wiederverwendbares Asset, das jedes autorisierte Teammitglied aufrufen kann.

Da der Agent in einem verwalteten Projekt definiert ist, werden sein Zugriff, seine Sichtbarkeit und sein Geltungsbereich genauso kontrolliert wie jede andere GitLab-Ressource – das gibt Plattformteams die nötige Sicherheit. Und jedes Artefakt, das der Agent erstellt – jedes Manifest, jeder Commit, jeder MR – lebt in GitLab: vollständig versioniert und auditierbar. Die Geschwindigkeit der KI-Automatisierung entsteht, ohne die Governance und Nachvollziehbarkeit zu opfern, die Unternehmen benötigen.

Heute einen Custom Agent aufbauen

Das Onboarding neuer Services in einen ausgereiften GitOps-Workflow ist ein gutes Beispiel für Aufgaben, die komplex genug sind, um sorgfältige Aufmerksamkeit zu erfordern, aber repetitiv genug, um Engineering-Kapazität zu binden. Ein Custom Agent auf der GitLab Duo Agent Platform verändert dieses Verhältnis. Er versteht die Anwendung und den organisationalen Kontext, folgt den eigenen Konventionen und produziert konsistente, überprüfbare Änderungen – während er vollständig versioniert, kontrolliert und sicher innerhalb von GitLab bleibt.

GitLab Duo Agent Platform lässt sich im Rahmen einer kostenlosen Testversion von GitLab Ultimate ausprobieren. Wer bereits Zugang zur GitLab Duo Agent Platform hat, findet weitere Informationen im Einstiegsleitfaden.