Wie eine Aufgabe zu einem pull request wird

Dies ist die Seite, auf die im restlichen Dokumentationstext verwiesen wird. Sie benennt jede Ausführungsphase, sodass andere Artikel präzise angeben können, wo etwas stattfindet.

Der Weg#

your description
   │
   ▼
   specification   what will be built, and how you will know it worked
   │
   ▼
   plan            the ordered steps, reviewed before any code is written
   │
   ▼
   build           code and tests written in an isolated workspace
   │
   ▼
   verify          your test suite, plus checks and quality gates
   │
   ▼
   review          an automated review pass over the diff
   │
   ▼
   pull request    on a branch, in your repository, waiting for you

Spezifikation#

Coroid beginnt nicht mit Ihrem Satz. Zuerst wird Ihre Beschreibung in eine Spezifikation: Was gebaut werden soll, was ausdrücklich außerhalb des Umfangs liegt und die Annahmekriterien, die festlegen, ob die Arbeit erfolgreich war.

Das ist wichtig, weil die Annahmekriterien die Grundlage für die spätere Überprüfungsphase bilden. Eine vage Spezifikation führt zu Arbeit, die schwer zu bewerten ist.

Sie können die Spezifikation auf der Aufgaben- Spezifikation Registerkarte vor Beginn der Ausführung einsehen und bearbeiten.

Der Leitfaden zur spezifikationsgesteuerten Entwicklung erläutert, wie Sie testbare Kriterien formulieren, den Umfang abgrenzen und dieselbe Definition von Erfolg durch Planung, Implementierung und Rezension hindurch beibehalten.

Planen#

Für alles, was über eine kleine Änderung hinausgeht, wird aus der Spezifikation ein Plan: eine geordnete Reihe von Schritten, gruppiert in Phasen. Sie genehmigen den Plan, bevor Code geschrieben wird.

Ein Plan kann kostengünstig abgelehnt werden – das ist die richtige Entscheidung, wenn der Ansatz falsch ist. Eine Ablehnung nach dem Schreiben des Codes ist hingegen teuer. In dieser Phase hat Ihr Urteil den größten Einfluss.

Erstellen#

Ein Agent kopiert das Repository in einen isolierten Arbeitsbereich und arbeitet dort. Er liest den Code, schreibt die Änderung und aktualisiert oder erstellt Tests.

Der Arbeitsbereich ist einzigartig pro Aufgabe und temporär nutzbar. Der Agent greift niemals auf Ihren Standard-Branch zu, und zwei gleichzeitig laufende Aufgaben können die jeweiligen Arbeitsergebnisse nicht gegenseitig einsehen.

Überprüfen#

Zuerst läuft Ihr eigenes Testpaket – das ist das stärkste Signal, da es widerspiegelt, was Ihr Team bereits als wichtig erachtet.

Darauf aufbauend führen Qualitätsprüfungen aus, was Ihre Organisation konfiguriert hat: Abdeckungsgrenzwerte, Linting, Sicherheitsscans sowie Browser-Tests gegen eine Vorschau-Deployment-Umgebung. Eine blockierende Prüfung stoppt die Aufgabe; eine empfehlende Prüfung zeichnet ein Ergebnis auf und lässt die Aufgabe fortfahren.

Rezension#

Ein Rezensions-Agent liest die Diff-Ansicht so, wie ein Kollege es tun würde, und erstellt Ergebnisse. Korrigierbare Ergebnisse werden zur Nachbesserung zurückgesendet; die übrigen werden der pull request zugeordnet, damit Sie sie sehen können.

Deshalb wird eine bereits überprüfte Coroid pull request bereitgestellt – nicht um Ihre Rezension zu ersetzen, sondern damit Ihre Rezension nicht die erste ist.

Pull-Request#

Der Branch wird gepusht und eine pull request wird gegen Ihren Basis-Branch geöffnet, wobei die Änderung, die Tests, die Überprüfungsergebnisse und die Rezensions-Ergebnisse enthalten sind.

Coroid endet hier. Das Zusammenführen übernehmen Sie.

Aufgaben-Status#

Der Status einer Aufgabe zeigt an, wo sie sich auf dem oben beschriebenen Weg befindet:

Was die Durchlaufrate bestimmt#

Ein Agenten-Slot verarbeitet jeweils eine Aufgabe gleichzeitig. Slots bestimmen, wie viel Arbeit parallel ausgeführt wird; sie beschleunigen jedoch keine einzelne Aufgabe. Die Dauer einer Aufgabe hängt von der Größe der Änderung und der Laufzeit Ihres Testpakets ab.

Weiter#

Agenten-Rollen – welcher Agent welche Phase übernimmt und welche Berechtigungen jeder einzelne besitzt.