Sprint Chains

Les Sprint Chains sont un mécanisme d’exécution par lot qui lance le même workflow plusieurs fois en séquence - une fois par sprint. Chaque sprint exécute le pipeline complet du workflow sur le repository du projet et produit sa propre pull request. Les sprint chains sont conçues pour le travail de développement par phases : lorsqu’une grande tâche est naturellement divisée en phases séquentielles qui méritent chacune leur propre cycle d’implémentation, revue et merge.

Sprint Chains vs. Work Chains

CodeCourier fournit deux mécanismes de chaîne, et la distinction importe :

• Sprint Chains - Exécutent le même workflowplusieurs fois. Chaque exécution est appelée un sprint. Le sprint 1 lance le workflow, le sprint 2 relance le même workflow sur la tâche suivante, et ainsi de suite. Utilisées lorsque vous voulez pousser un workflow à travers plusieurs phases de travail, chacune produisant une PR distincte.
• Work Chains - Exécutent différentes issuesà travers un seul workflow. Chaque élément de la work chain est une tâche différente, toutes traitées à travers le même pipeline. Utilisées pour traiter par lot un backlog d’issues via une file automatisée.

Modèle de données des Sprint Chains

Un enregistrement de sprint chain capture toute la configuration et l’état d’exécution de l’exécution par lot :

{
  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)
}

Le tableau sprintPrUrls est aligné par index sur la séquence de sprints. sprintPrUrls[0] contient la PR du sprint 1, sprintPrUrls[1] celle du sprint 2, et ainsi de suite. Les sprints qui ne sont pas encore terminés ont undefined à leur index.

Créer une Sprint Chain

Les sprint chains sont créées et gérées depuis la page Runs (/p/[id]/runs) à l’aide du sprint chain launcher.

Cycle de vie de l’exécution

L’orchestrateur de sprint chain gère l’exécution à travers tous les sprints. Le cycle de vie suit un pattern strictement séquentiel :

Transitions de statut de chaîne

• pending - La chaîne a été créée mais le premier sprint n’a pas démarré. C’est un état transitoire bref.
• running - Un sprint s’exécute activement. Le champ currentSprintIndex reflète quel sprint est en cours.
• completed - Tous les sprints se sont terminés avec succès. Chaque sprint a produit un run et (si du code a été changé) une pull request.
• failed - Un sprint a rencontré une erreur irrécupérable qui a empêché la chaîne de continuer. L’enregistrement de la chaîne capture quel sprint a échoué.
• cancelled - L’utilisateur a arrêté manuellement la chaîne avant l’achèvement de tous les sprints.

Création de run par sprint

Pour chaque sprint, l’orchestrateur crée un enregistrement de workflow run standard avec :

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

Lorsque le run du sprint se termine et qu’une PR est créée, l’orchestrateur de chaîne capture l’URL de la PR dans sprintPrUrls à l’index du sprint actuel, puis fait avancer currentSprintIndex et démarre le sprint suivant.

Séquencement des sprints

Les sprints sont strictement séquentiels - le sprint 2 ne démarre pas tant que le run du sprint 1 n’est pas entièrement terminé (statut completed ou failed). Cela garantit que chaque sprint peut s’appuyer sur les changements de code commités par le sprint précédent. La branche utilisée à travers les sprints est généralement la même branche de fonctionnalité, de sorte que les commits de chaque sprint s’empilent sur le travail des sprints précédents.

Suivi des PR par sprint

L’une des fonctionnalités clés des sprint chains est le suivi des pull requests par sprint. Chaque sprint qui produit des changements de code crée sa propre pull request. Le tableau sprintPrUrls enregistre ces URLs, vous donnant une piste d’audit complète de ce qui a été livré à chaque phase de sprint.

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)
]

Les URLs de PR dans sprintPrUrls sont affichées sur la vue détaillée de la sprint chain, vous donnant des liens directs pour revoir la sortie de chaque sprint sans naviguer dans la liste complète des runs.

Reprise depuis un sprint

Les sprint chains prennent en charge une capacité de reprise depuis un sprint. Si une chaîne échoue ou est annulée avant de se terminer, vous pouvez la redémarrer à partir d’un sprint spécifique plutôt que de réexécuter toute la séquence.

Le champ resumeFromSprint de l’enregistrement de la sprint chain contrôle à partir de quel index de sprint l’orchestrateur démarre lorsque la chaîne est reprise. Définir resumeFromSprint = 2(indexé à zéro) signifie que la chaîne commence au sprint 3, en sautant les sprints 1 et 2.

Annuler une Sprint Chain

Vous pouvez annuler une sprint chain en cours d’exécution à tout moment depuis la vue détaillée de la sprint chain. L’annulation :

1. Définit le statut de la chaîne à cancelled.
2. Annule le workflow run du sprint en cours d’exécution s’il est encore en cours.
3. Empêche les sprints suivants de démarrer.

Toutes les PR de sprint créées avant l’annulation restent ouvertes dans GitHub. Le travail commité sur la branche est préservé et peut être repris à l’aide de la capacité de reprise.

Cas d’usage

• Développement de fonctionnalité itératif - Le sprint 1 échafaude le modèle de données et l’API, le sprint 2 construit l’interface, le sprint 3 ajoute les tests, le sprint 4 gère les cas limites. Chaque sprint produit une PR révisable.
• Migrations par phases - Le sprint 1 migre la bibliothèque de composants A, le sprint 2 migre la bibliothèque B, le sprint 3 met à jour tous les consommateurs. Chaque sprint est une unité de changement sûre et indépendante.
• Améliorations de qualité de code par lot - Chaque sprint exécute le même workflow de qualité sur un module différent de la codebase, avec des prompts par sprint ciblant des répertoires spécifiques.
• Couverture de test incrémentale - Sprint après sprint, un workflow ajoute de la couverture de test à différentes zones, chaque sprint ciblant un package ou un domaine de fonctionnalité différent.
• Mises à jour de dépendances progressives - Le sprint 1 met à jour un ensemble de dépendances, le sprint 2 met à jour le suivant, évitant une PR massive avec des centaines de conflits.

Surveiller les Sprint Chains

Les sprint chains sont visibles à deux endroits :

• Liste des Runs - Les runs de sprint individuels apparaissent avec la source sprint. Utilisez le filtre de source pour les isoler.
• Vue détaillée de la sprint chain - Montre le statut de la chaîne, l’index de sprint actuel, toutes les URLs de PR de sprint et une timeline des exécutions de sprint. Accessible depuis l’entrée de la chaîne dans la navigation de la page Runs.

Des notifications sont envoyées lorsque la chaîne se termine (sprint_completed) ou échoue (sprint_failed), afin que vous n’ayez pas besoin de surveiller activement l’exécution.