Technische Vorgänge strukturiert bearbeiten
Von der Infrastruktur-Störung bis zur Softwareänderung.
Vorgänge werden als Issues in GitLab abgebildet – Workflows übernehmen die Analyse, Implementierung, Validierung und Merge Requests.
Das Issue bleibt der nachvollziehbare Bezugspunkt. Der eigentliche Ablauf richtet sich nach Ursache, Kontext, Labels und benötigten Fähigkeiten.
Ein technischer Vorgang beginnt nicht immer mit Software.
Am Anfang steht häufig ein Infrastrukturproblem, eine Supportmeldung oder eine automatisiert erkannte Auffälligkeit.
In GitLab wird dieser Vorgang festgehalten und ein Workflow entscheidet anschließend, welche Funktionen benötigt werden. Daraus ergibt sich dann der Einsatz eines Agent, einer LLM oder von klassischen GitLab-Funktionen.
Fehlgeschlagene Checks oder erkannte Auffälligkeiten
Kundenmeldung, Diagnose oder Rückfrage
VPN, Storage, Backup oder Netzwerk
Bugfix, Feature, Refactoring oder technische Anpassung
Vom technischen Ereignis zum passenden Workflow
GitLab ist nicht der Workflow selbst. Es ist die zentrale Stelle, an der Aufgaben, Zustände, Kommentare, Ergebnisse und Folgeaktivitäten zusammenlaufen.
Ein Issue kann unterschiedliche Wege nehmen
Infrastruktur & Support
Beispiel: Dienst nicht erreichbar
Ein Monitoring-Check erkennt ein Problem und erzeugt beziehungsweise aktualisiert einen technischen Vorgang in GitLab.
Softwareentwicklung
Beispiel: Bugfix oder Feature
Beschreibt das Issue eine Softwareänderung, kann der Workflow Branch, Implementierung, Validierung, CI und Review koordinieren.
GitLab als kontrollierte technische Capability
Workflows greifen nicht unstrukturiert auf GitLab zu, sondern verwenden klar definierte Funktionen für Vorgänge, Repository-Inhalte, Reviews und CI.
Issues
Vorgänge erstellen, lesen, aktualisieren, kommentieren und miteinander verknüpfen.
Repository
Branches, Dateien, Commits und Projektinhalte kontrolliert für Workflows bereitstellen.
Merge Requests
Softwareänderungen nachvollziehbar bündeln und in einen Review-Prozess übergeben.
Pipelines
CI-Status prüfen, Pipelines starten und Job-Ergebnisse in den Workflow einbeziehen.
Ein möglicher Ablauf für Softwareänderungen
Precheck
Ist das Issue noch offen und relevant? Gibt es bereits einen parallelen oder abgeschlossenen Merge Request?
Workspace & Branch
Das Repository wird synchronisiert und ein issue-spezifischer Arbeitsbranch vorbereitet.
Planen & Implementieren
Das LLM erhält gezielt den benötigten Kontext und setzt die Aufgabe im Workspace um.
Validieren & Review
Erst nach definierten Prüfungen und CI wird der Merge Request erstellt und ein Review-Workflow gestartet.
Qualitäts-Gates vor dem Merge Request
Die Implementierung eines Agents wird nicht automatisch mit einem fertigen Merge Request gleichgesetzt.
Fehler können als Korrekturhinweis an dieselbe LLM-Session zurückgegeben werden. Erst wenn die Gates erfolgreich sind, geht der Vorgang weiter.
Nicht jeder GitLab-Workflow braucht ein LLM
Wiederholbare Verwaltungsschritte werden bewusst deterministisch umgesetzt. Dadurch bleibt der Ablauf einfacher, schneller und besser vorhersehbar.
Ein eigener Workflow kann beispielsweise ein neues Issue erstellen, es mit bestehenden Vorgängen verknüpfen, Cross-References setzen und anschließend die Existenz verifizieren.
Titel, Beschreibung und Labels aus vorbereiteten Eingaben
Beziehungen zu bestehenden Issues herstellen
Parent-Issue automatisch aktualisieren
Ergebnis prüfen und nächsten Workflow starten
Handoff statt Sackgasse
Kann ein Agent eine Aufgabe nicht übernehmen oder fällt ein LLM-Provider temporär aus, kann der Workflow an den nächsten erlaubten Agent übergeben werden. Der technische Vorgang bleibt dabei derselbe und seine Historie bleibt in GitLab nachvollziehbar.
Temporäre Probleme können erneut versucht oder an einen anderen Agent weitergereicht werden.
Wird ein Fehler als Tooling- oder Infrastrukturproblem klassifiziert, kann daraus ein eigener technischer Vorgang entstehen.
Ist eine automatische Lösung nicht sinnvoll, bleibt der Vorgang mit Fehlerkontext und Historie sichtbar.
Der Support erhält nicht nur eine Fehlermeldung, sondern den bereits gesammelten technischen Kontext.
Vorteile
Support, Infrastruktur und Entwicklung arbeiten auf derselben dokumentierten Historie.
Sprach- und Codeverständnis nur dort verwenden, wo deterministische Logik nicht ausreicht.
Kommentare, Labels, Issues, Merge Requests und Pipelines bleiben Teil des Vorgangs.
Derselbe Einstiegspunkt kann zu Infrastrukturmaßnahmen, Support oder Softwareänderungen führen.