So führt Upsun Dispatch Workflows durch – vom Issue bis zum geprüften Programm

Upsun Dispatch ist ab heute allgemein öffentlich verfügbar. In unserem vorherigen Artikel erklären wir, was es ist und warum wir es entwickelt haben. Dieses Mal gehen wir näher darauf ein, wie es funktioniert, aus welchen Grundbausteinen es besteht und welche Funktionen sofort verfügbar sind. Am Ende des Artikels bekommst du außerdem einen Einblick in unsere Roadmap.

Die Grundbausteine

Upsun Dispatch verfügt über drei große Bausteine: Workflow, Sandbox und Integrationen. Der Kern unseres Produkts ist der Workflow. Schauen wir uns das genauer an.

Ein Workflow ist eine Abfolge von Schritten, die euch von einem Auslöser zu einem definierten Ergebnis führt. Derzeit enthält jeder Workflow eine feste Reihe von Schritten, die Agenten oder Menschen ausführen können. Unser Ziel ist es, euch nach und nach die Möglichkeit zu geben, bestehende Workflows zu bearbeiten und sogar eigene von Grund auf neu zu erstellen. Damit ein Workflow funktioniert, müsst ihr ihn mit einer externen Quelle verbinden, mit der er interagieren soll, und den Auslösertyp definieren, der die Ausführung startet.

Das war ein allgemeiner Überblick über unsere wichtigste Workflow-Grundkomponente. Schauen wir uns nun die Unterkomponenten an.

Ein Auslöser ist die Startbedingung für die Ausführung. Auslöser können automatisch ausgelöst werden, wenn in einem verbundenen System ein Ereignis erkannt wird, wie zum Beispiel das Eröffnen eines Pull-Requests oder eines Merge-Requests in GitHub bzw. GitLab. Ein Nutzer kann eine Ausführung manuell starten; in den meisten Fällen handelt es sich dabei um die Erwähnung eines Agenten in einer der Workflow-Eingaben.

Ein „Lauf“ ist eine einzelne Ausführung eines Workflows. Er enthält Informationen wie: Wer hat ihn gestartet, auf welche Daten hatte der Agent Zugriff, die Ergebnisse und die Dauer jedes Schritts, wer die Entscheidung getroffen hat und das Endergebnis. Du kannst alle Läufe innerhalb deiner Upsun Dispatch-Organisation einsehen. Der Lauf ist das, was du auf der Lauf-Seite öffnest.

Ein „Schritt“ ist eine einzelne Aktion im Workflow. Ein Schritt hat eine Startbedingung, erwartete Eingaben und Ausgaben, ein Timeout und eine Wiederholungsrichtlinie. Jeder Schritt ist entweder ein deterministischer Schritt, der vom System ausgeführt wird, ein Schritt, der von einem Agenten bearbeitet wird, oder ein Schritt, der menschliches Eingreifen erfordert.

Ein „Human Gate“ ist ein spezifischer Schritt, der menschliches Eingreifen erfordert. Am Starttag gibt es im Produkt ein solches Gate: die Planfreigabe im „Issue to Code“-Workflow. Du kannst es ein- oder ausschalten, je nachdem, wie sehr du den Agenten vertraust. Sobald der Workflow ein „Human Gate“ erreicht, wird der Durchlauf angehalten, bis der Nutzer die Fortsetzung der Ausführung genehmigt.

Nachdem wir nun die Hauptprimitive und ihre Unterprimitiven kennengelernt haben, schauen wir uns zwei weitere Primitive an, die Upsun Dispatch bietet.

Die Sandbox ist eine isolierte Umgebung, die für einen einzelnen Agenten-Schritt erstellt und danach wieder gelöscht wird. Der Agent hat Zugriff auf die Daten, die bei der Erstellung in die Sandbox geladen wurden. Da die Sandbox nur für einen Schritt existiert, führt ein Workflow mit mehreren Agenten-Schritten jeden Schritt in einer eigenen Sandbox aus.

„Integration“ ist eine Verbindung zwischen Upsun Dispatch und einem Tool, das dein Team bereits nutzt.

Die Primitive in Aktion: vom Jira-Issue zum geprüften Pull-Request

Primitives sind abstrakt, bis du sie in einem Durchlauf siehst. Schauen wir uns also ein alltägliches Beispiel an: Ein Produktmanager fordert in Jira eine Änderung an, und wenige Minuten später wartet ein geprüfter Pull-Request auf GitHub.

So löst du den Durchlauf aus

Ein Produktmanager öffnet ein Jira-Board und sieht ein gut beschriebenes Ticket. Es handelt sich um eine wichtige Änderung, auf die die Nutzer schon seit einiger Zeit warten. Der Produktmanager beschließt, dass es Zeit ist, das zu erledigen. Er öffnet das Ticket und fügt einen Kommentar hinzu: @Upsun Dispatch implementieren.

Dieser Kommentar ist ein Auslöser. Bevor der eigentliche Ablauf startet, prüft Upsun Dispatch zwei Dinge: ob der Kommentar Upsun Dispatch korrekt anspricht und ob die Person über ausreichende Rechte verfügt, um Upsun Dispatch in diesem Jira-Projekt auszulösen. Upsun Dispatch ignoriert Erwähnungen von Personen ohne Zugriff, und es startet kein Ablauf. Eine reine Erwähnung ohne Befehl zeigt die Liste der Befehle an, die das Ticket akzeptiert, und es wird ebenfalls nichts ausgeführt.

Jira selbst ist eine Integration. Jede Integration übersetzt die Ereignisse ihres Tools – einen Jira-Kommentar, einen GitHub-Pull-Request, eine Linear-Zuweisung – in ein gemeinsames Format, bevor sie den Workflow erreichen. Deshalb ist „Issue to Code“ ein einziger Workflow mit Eingabe- und Ausgabequellen: Er weiß nicht und kümmert sich auch nicht darum, aus welchem Tool die Anfrage stammt.

Sobald der Auslöser akzeptiert wurde, erscheint ein Lauf ganz oben im Upsun-Dispatch-Dashboard, sichtbar für alle in deiner Organisation. Von nun an wird alles, was passiert, damit verknüpft: wer die Anfrage gestellt hat, was der Bearbeiter gesehen hat, was jeder Schritt hervorgebracht hat, wie lange es gedauert hat, wer entschieden hat und was es gekostet hat.

Schritt eins: Den Kontext erfassen

Der erste Schritt ist deterministisch. Er ruft das Ticket, dessen Kommentare, die verknüpften Tickets und Pull-Anfragen sowie alle erwähnten Dateien ab. Außerdem prüft er, ob im Tickettext angegeben ist, in welches Repo der Code hinzugefügt werden soll, da Jira-Tickets diese Information standardmäßig nicht enthalten.

Diese Daten werden für den Durchlauf gespeichert. Wer den Plan später genehmigt, kann ihn öffnen und genau sehen, welche Eingaben der Agent erhalten hat. Das ist der Teil, den die meisten Agent-Tools überspringen, und genau dieser Teil macht die Genehmigung erst sinnvoll. Du genehmigst keinen Plan blind, sondern mit einem klaren Überblick über den Kontext, aus dem er entstanden ist.

Schritt zwei: Plan

Sobald wir den Kontext erfasst haben, gehen wir zu unserem ersten agentenbasierten Schritt über. Ein Planungsagent liest das Kontextpaket und erstellt einen Plan.

Er läuft in einer Sandbox: einer isolierten Umgebung, die ausschließlich für diesen Schritt erstellt wurde, die das Kontextbündel enthält und die in dem Moment gelöscht wird, sobald der Schritt endet. Der ausgehende Netzwerkzugriff ist standardmäßig gesperrt. Was auch immer der Agent tut, er tut es innerhalb dieser Sandbox.

Wenn der Plan fertig ist, veröffentlicht ein weiterer deterministischer Schritt ihn als Kommentar zum Jira-Ticket, denn von dort aus wurde der Lauf ausgelöst. Upsun Dispatch protokolliert ihn ebenfalls, sodass du später alle Details zum Lauf an einem Ort finden kannst.

Die menschliche Kontrollinstanz

Wenn deine Organisation diese Funktion aktiviert hat, hält der Lauf nun an der menschlichen Kontrollstelle an. Der Workflow wird angehalten, bis eine Person den Plan genehmigt.

Die Entscheidung wird im Jira-Ticket getroffen, wobei einer der drei Befehle verwendet wird:

• @Upsun Dispatch plan approve setzt die Umsetzung der vom Planungsagenten vorgeschlagenen Maßnahmen fort.
• @Upsun Dispatch plan reject <Grund> beendet den Lauf und protokolliert den Grund für die Ablehnung im Lauf.
• @Upsun Dispatch plan revise <Feedback> schickt den Durchlauf mit deinem beigefügten Feedback zurück zum Planungsschritt. Ein neuer Plan ersetzt den alten. Jede Iteration wird protokolliert.

Wenn sieben Tage lang niemand antwortet, läuft das Gate ab und der Durchlauf endet.

Ob das Gate aktiviert oder deaktiviert ist, entscheidet deine Organisation. Teams, die dem Planungsagenten bei kleinen Änderungen vertrauen, schalten es aus. Teams, die bei jeder Änderung eine Person in den Prozess einbeziehen wollen, lassen es aktiviert. So oder so werden die Entscheidung und der Entscheidungsträger im Durchlauf protokolliert.

Schritt drei: Programmieren

Unser Produktmanager gibt die Freigabe. Der Programmier-Agent startet in einer neuen Sandbox, mit dem geklonten Repository und dem genehmigten Plan als Eingabe. Zwei Dinge zu dieser Sandbox solltest du wissen.

Das Repository-Token, das der Agent verwendet, ist schreibgeschützt und auf dieses eine Repository beschränkt. Es wird auf Netzwerkebene eingefügt, sodass der Agent es niemals besitzt. Und der Agent kann von innerhalb der Sandbox aus keinen Branch pushen oder einen Pull-Request öffnen. Das übernimmt ein späterer, deterministischer Schritt. Der Agent schreibt die Änderung als Schritt-Ausgabe.

Schritt vier: Kritik

Bevor irgendetwas GitHub erreicht, liest ein dritter Agent – der Kritiker – den Diff, den der Agent zum Programmieren erstellt hat. Er läuft in seiner eigenen Sandbox als eigenständiger Schritt und sieht nur den Diff, nicht das gesamte Repository. Stell dir ihn als ersten reviewer vor, der die Änderung liest, bevor es irgendjemand anderes tut.

Er stellt zwei Arten von Fragen: Hat die Änderung das bewirkt, was verlangt wurde? Der Kritiker vergleicht den Diff mit dem genehmigten Plan und markiert Ziele, die übersprungen, nur halb umgesetzt oder stillschweigend eingeschränkt wurden. Und ist das, was erstellt wurde, fehlerfrei? Logikfehler, fehlende Fehlerbehandlung, Geheimnisse oder Injektionsrisiken im neuen Code, Abstürze bei leerer Eingabe, eine geänderte Signatur, die ihre Aufrufer lahmlegt. Stilistische Kleinigkeiten werden bewusst außer Acht gelassen. Eine leere Liste mit Befunden bedeutet, dass die Änderung fehlerfrei aussah.

Die Ergebnisse werden in die Beschreibung des Pull-Requests geschrieben, sodass der menschliche Reviewer den Pull-Request öffnet und die Anmerkungen des Kritikers bereits vorfindet. Wenn der Kritiker jedoch eine Änderung entdeckt, die sich nicht einmal kompilieren lässt – zum Beispiel einen Syntaxfehler in einer hinzugefügten Zeile –, lässt er den Pull-Request nicht öffnen. Der Lauf bricht ab und gibt im Jira-Issue den Grund an, und du entscheidest, ob du es noch einmal versuchen willst.

Schritt fünf: der Pull-Request

Ein deterministischer Schritt pusht den Branch und eröffnet den Pull-Request auf GitHub. Der Autor des Commits ist die Person, die die Umsetzung angefordert hat. Dispatch ist der Committer und Mitautor. Die Git-Historie zeigt, wer dies gewünscht hat und wer die Arbeit erledigt hat. Ein Kommentar mit dem Link erscheint im Jira-Issue.

Der Zweigname ist pro Ticket fest, sodass ein zweiter Lauf für dasselbe Ticket in denselben Pull-Request pusht, anstatt einen konkurrierenden zu eröffnen.

Ein letzter Schritt überprüft, ob tatsächlich ein Pull-Request eröffnet wurde. War dies nicht der Fall, wird der Durchlauf als fehlgeschlagen und nicht als abgeschlossen gemeldet.

Schritt sechs: die Überprüfung

Der Push löst einen weiteren Workflow aus. Die Code-Review beginnt für den neuen Pull-Request, genau wie bei jedem Pull-Request in diesem Repository, einschließlich derer, die Dispatch eröffnet. Das Programm liest den Diff und das verknüpfte Ticket, überprüft die CI und veröffentlicht eine Review auf GitHub. Es führt niemals einen Merge durch. Dein Branch-Schutz entscheidet wie bisher darüber, was in die Produktivumgebung gelangt.

Was du am Tag der Einführung bekommst

Nachdem wir nun alle Grundfunktionen durchgesehen haben, schauen wir uns an, was in Upsun Dispatch ab heute verfügbar ist.

Du startest mit drei Workflows.

Die Code-Review läuft bei Pull-Requests auf GitHub und bei Merge-Requests auf GitLab. Sie vergleicht den Diff mit dem verknüpften Issue, kennzeichnet Architekturprobleme und kompatibilitätsbrechende Änderungen und veröffentlicht einen Review im Tool. Sie läuft automatisch bei jeder Änderung oder auf Anfrage mit dem Befehl @upsun-dispatch review.

„Issue to Code“ ist der Workflow, den wir gerade durchlaufen haben. Er beginnt mit einer Erwähnung in einem GitHub-Issue, einer Erwähnung in einem Jira-Issue oder einer Zuweisung in Linear und öffnet die Änderung auf GitHub oder – von Linear aus – auf GitLab. „Plan approval“ ist die oben beschriebene Organisationseinstellung.

Der CVE-Scan überprüft die Abhängigkeiten eines Repositorys auf bekannte Sicherheitslücken und meldet die Ergebnisse.

Zusätzlich zu den Workflows stehen dir auch Integrationen für GitHub, GitLab, Jira und Linear zur Verfügung. Reviewer und Genehmiger agieren über das Tool, das sie ohnehin schon nutzen; Schreibzugriff dort reicht aus. Jeder in der Organisation sieht jeden Durchlauf. Die Agentenzeit und die Tokens werden pro Durchlauf angezeigt, und auf der Seite „Nutzung“ werden sie nach Workflow und Repository gruppiert. Du bringst deinen eigenen Modellschlüssel mit – sei es von Anthropic oder OpenAI – und die Tokens werden über deinen Anbieter abgerechnet. Die Agentenzeit wird aus einem Prepaid-Guthaben bezahlt, ohne Preis pro Nutzer und ohne Repository-Limit. Und es gibt einen kostenlosen Tarif: 20 Agentenminuten pro Tag, keine Kreditkarte erforderlich.

Ein Blick auf die Roadmap

Wir haben zuerst die Grundbausteine entwickelt, bevor wir die Features umgesetzt haben, und in den nächsten Monaten geht es darum, diese zugänglich zu machen.

Derzeit sind die Workflows fest vorgegeben. Du kannst das Gate ein- oder ausschalten, den Trigger auf „automatisch“ oder „manuell“ einstellen und Optionen pro Repository festlegen, aber du kannst keinen Schritt hinzufügen oder einen eigenen schreiben. Bearbeitbare Workflows, die dasselbe Vokabular für Schritte und Gates verwenden, das du gerade gelesen hast, sind das Nächste, was wir veröffentlichen werden.

Derzeit wird bei jedem Durchlauf der Kontext neu erfasst. Persistentes Projektwissen, das für dein Team sichtbar und bearbeitbar ist, folgt danach.

Derzeit hat die Überprüfung nur beratenden Charakter und behebt die gefundenen Probleme nicht. Ein Workflow zur automatischen Behebung ist in Vorbereitung; dieser wird eine Änderung zur Genehmigung durch eine Person eröffnen, anstatt sie direkt zusammenzuführen.

Derzeit sind Trigger Ereignisse in verbundenen Tools sowie manuelle Ausführungen. Geplante Ausführungen folgen in Kürze.

Der Teil, den nur ein Plattformunternehmen hinzufügen kann, ist die Verifizierung: eine reale Umgebung für eine Änderung einrichten, sie dort ausführen und anschließend wieder abbauen. Das ist die Fähigkeit, auf die wir hinarbeiten, wobei wir unser Erbe aus der Upsun cloud nutzen.

Probier es doch mal mit einem Issue aus, das du bereits hast

Fang nicht mit dem Pull-Request an, sondern mit dem Issue. Bitte Upsun Dispatch, die Änderung zu implementieren, und gehe dann zu „Runs“. Öffne das Kontext-Bundle und überprüfe, ob der Agent über alles verfügte, was ein Kollege benötigt hätte. Lies den Plan, bevor du dir den Diff ansiehst. Lies anschließend die Überprüfung, die Upsun Dispatch in seinem eigenen Pull-Request gepostet hat. Wenn diese Kette Sinn ergibt, erfüllt das Produkt seinen Zweck. Falls ein Glied in der Kette fehlt, sag uns Bescheid, denn die Kette ist das Produkt.

Bereit loszulegen? Melde dich an, verbinde ein Repository, füge deinen Modellschlüssel hinzu und erwähne Upsun Dispatch in einem Issue, das du bereits hast.