Sprint Chains

Sprint Chains sind ein Batch-Ausführungsmechanismus, der denselben Workflow mehrfach hintereinander ausführt - einmal pro Sprint. Jeder Sprint führt die vollständige Workflow-Pipeline gegen das Projekt-Repository aus und erzeugt seinen eigenen Pull-Request. Sprint Chains sind für phasenweise Entwicklungsarbeiten konzipiert: wenn eine große Aufgabe natürlich in sequenzielle Phasen aufgeteilt ist, die jeweils einen eigenen Implementierungs-, Review- und Merge-Zyklus verdienen.

Sprint Chains vs. Work Chains

CodeCourier bietet zwei Chain-Mechanismen, und die Unterscheidung ist wichtig:

• Sprint Chains - Führen denselben Workflow mehrfach aus. Jede Ausführung wird als Sprint bezeichnet. Sprint 1 führt den Workflow aus, Sprint 2 führt denselben Workflow erneut auf der nächsten Aufgabe aus und so weiter. Wird verwendet, wenn Sie einen Workflow durch mehrere Arbeitsphasen schieben wollen, wobei jede einen separaten PR liefert.
• Work Chains - Führen verschiedene Issues durch einen einzigen Workflow aus. Jedes Element der Work Chain ist eine andere Aufgabe, alle werden durch dieselbe Pipeline verarbeitet. Wird zum Batch-Processing eines Issue-Backlogs über eine automatisierte Queue verwendet.

Sprint-Chain-Datenmodell

Ein Sprint-Chain-Datensatz erfasst die vollständige Konfiguration und den Laufzeitzustand der Batch-Ausführung:

{
  userId: string,               // Owner who created the chain
  projectId: string,            // Project the chain belongs to
  workflowId: string,           // Workflow blueprint to execute each sprint
  status: "pending"             // Chain lifecycle state
        | "running"
        | "completed"
        | "failed"
        | "cancelled",
  sprintRange: number,          // Total number of sprints (e.g., 5)
  currentSprintIndex: number,   // Zero-based index of the in-progress sprint
  resumeFromSprint: number,     // Sprint index to restart from (for recovery)
  sprintPrUrls: string[],       // PR URL created per sprint (index-aligned)
}

Das Array sprintPrUrls ist index-aligned zur Sprint- Sequenz. sprintPrUrls[0] enthält den PR von Sprint 1, sprintPrUrls[1] von Sprint 2 und so weiter. Sprints, die noch nicht abgeschlossen sind, haben undefined an ihrem Index.

Eine Sprint Chain erstellen

Sprint Chains werden auf der Runs-Seite erstellt und verwaltet (/p/[id]/runs) über den Sprint-Chain-Launcher.

Ausführungs-Lebenszyklus

Der Sprint-Chain-Orchestrator verwaltet die Ausführung über alle Sprints. Der Lebenszyklus folgt einem strikt sequenziellen Muster:

Chain-Status-Übergänge

• pending - Die Chain wurde erstellt, aber der erste Sprint hat noch nicht begonnen. Dies ist ein kurzer Übergangszustand.
• running - Ein Sprint wird aktiv ausgeführt. Das Feld currentSprintIndex zeigt, welcher Sprint gerade läuft.
• completed - Alle Sprints wurden erfolgreich abgeschlossen. Jeder Sprint hat einen Run und (sofern Code geändert wurde) einen Pull-Request erzeugt.
• failed - Ein Sprint ist auf einen nicht behebbaren Fehler gestoßen, der die Chain am Fortfahren gehindert hat. Der Chain-Datensatz erfasst, welcher Sprint fehlgeschlagen ist.
• cancelled - Der Nutzer hat die Chain manuell gestoppt, bevor alle Sprints abgeschlossen waren.

Erstellung von Runs pro Sprint

Für jeden Sprint erstellt der Orchestrator einen Standard-Workflow-Run-Datensatz mit:

{
  source: "sprint",            // Identifies the run as sprint-originated
  workflowId: chain.workflowId,
  prompt: sprintPrompt,        // The sprint's prompt (base or per-sprint)
  // ... standard run configuration
}

Sobald der Run des Sprints abgeschlossen und ein PR erstellt ist, erfasst der Chain- Orchestrator die PR-URL in sprintPrUrls am Index des aktuellen Sprints, erhöht dann currentSprintIndex und beginnt den nächsten Sprint.

Sprint-Sequenzierung

Sprints sind streng sequenziell - Sprint 2 startet nicht, bevor der Run von Sprint 1 vollständig abgeschlossen ist (Status completedoder failed). Das stellt sicher, dass jeder Sprint auf den Code-Änderungen des vorherigen Sprints aufbauen kann. Der über Sprints hinweg verwendete Branch ist typischerweise derselbe Feature-Branch, sodass die Commits jedes Sprints auf der Arbeit vorheriger Sprints aufbauen.

PR-Tracking pro Sprint

Eines der Schlüsselmerkmale von Sprint Chains ist das Tracking von Pull-Requests pro Sprint. Jeder Sprint, der Code-Änderungen erzeugt, erstellt seinen eigenen Pull- Request. Das Array sprintPrUrls protokolliert diese URLs und gibt Ihnen eine vollständige Audit-Spur dessen, was in jeder Sprint-Phase geliefert wurde.

sprintPrUrls: [
  "https://github.com/org/repo/pull/42",  // Sprint 1 PR
  "https://github.com/org/repo/pull/43",  // Sprint 2 PR
  "https://github.com/org/repo/pull/44",  // Sprint 3 PR
  undefined,                               // Sprint 4 (not yet run)
  undefined,                               // Sprint 5 (not yet run)
]

Die PR-URLs in sprintPrUrls werden in der Sprint-Chain- Detailansicht angezeigt und geben Ihnen direkte Links zum Review der Ausgabe jedes Sprints, ohne durch die vollständige Runs-Liste navigieren zu müssen.

Ab Sprint fortsetzen

Sprint Chains unterstützen eine Resume-from-Sprint-Funktion. Wenn eine Chain vor dem Abschluss fehlschlägt oder abgebrochen wird, können Sie sie ab einem beliebigen Sprint neu starten, statt die gesamte Sequenz erneut auszuführen.

Das Feld resumeFromSprint im Sprint-Chain-Datensatz steuert, bei welchem Sprint-Index der Orchestrator nach einem Resume startet. Setzt manresumeFromSprint = 2 (null-indiziert), beginnt die Chain bei Sprint 3 und überspringt Sprints 1 und 2.

Eine Sprint Chain abbrechen

Sie können eine laufende Sprint Chain jederzeit über die Sprint-Chain- Detailansicht abbrechen. Der Abbruch:

1. Setzt den Chain-Status auf cancelled.
2. Bricht den Workflow-Run des aktuell laufenden Sprints ab, falls er noch aktiv ist.
3. Verhindert, dass nachfolgende Sprints starten.

Alle vor dem Abbruch erstellten Sprint-PRs bleiben in GitHub geöffnet. Arbeit, die in den Branch committet wurde, bleibt erhalten und kann über die Resume- Funktion fortgesetzt werden.

Anwendungsfälle

• Iterative Feature-Entwicklung - Sprint 1 baut das Datenmodell und die API auf, Sprint 2 baut die UI, Sprint 3 fügt Tests hinzu, Sprint 4 behandelt Edge Cases. Jeder Sprint erzeugt einen review-baren PR.
• Phasenweise Migrationen - Sprint 1 migriert die Komponenten-Bibliothek A, Sprint 2 migriert Bibliothek B, Sprint 3 aktualisiert alle Konsumenten. Jeder Sprint ist eine sichere, unabhängige Änderungs-Einheit.
• Batch-Verbesserungen der Code-Qualität - Jeder Sprint führt denselben Qualitäts-Workflow gegen ein anderes Modul der Codebasis aus, mit Prompts pro Sprint, die spezifische Verzeichnisse ansprechen.
• Inkrementelle Testabdeckung - Sprint für Sprint fügt ein Workflow Testabdeckung in verschiedenen Bereichen hinzu, wobei jeder Sprint ein anderes Paket oder eine andere Feature-Domain anvisiert.
• Rollende Abhängigkeits-Updates - Sprint 1 aktualisiert einen Satz Abhängigkeiten, Sprint 2 den nächsten, was einen massiven PR mit Hunderten von Konflikten vermeidet.

Sprint Chains überwachen

Sprint Chains sind an zwei Stellen sichtbar:

• Runs-Liste - Einzelne Sprint-Runs erscheinen mit Quelle sprint. Verwenden Sie den Quellfilter, um sie zu isolieren.
• Sprint-Chain-Detailansicht - Zeigt den Chain- Status, den aktuellen Sprint-Index, alle Sprint-PR-URLs und eine Zeitleiste der Sprint-Ausführungen. Erreichbar über den Eintrag der Chain in der Runs-Seitenleiste.

Benachrichtigungen werden gesendet, wenn die Chain abgeschlossen wird (sprint_completed) oder fehlschlägt (sprint_failed), sodass Sie die Ausführung nicht aktiv überwachen müssen.