Sprint Chain

Le Sprint Chain sono un meccanismo di esecuzione batch che lancia lo stesso workflow più volte in sequenza - una volta per sprint. Ogni sprint esegue l’intera pipeline del workflow sul repository del progetto e produce la propria pull request. Le sprint chain sono progettate per il lavoro di sviluppo a fasi: quando un task grande è naturalmente diviso in fasi sequenziali che meritano ciascuna il proprio ciclo di implementazione, revisione e merge.

Sprint Chain vs. Work Chain

CodeCourier fornisce due meccanismi di chain, e la distinzione conta:

• Sprint Chain - Eseguono lo stesso workflowpiù volte. Ogni esecuzione è chiamata sprint. Lo sprint 1 lancia il workflow, lo sprint 2 rilancia lo stesso workflow sul task successivo, e così via. Usate quando vuoi spingere un workflow attraverso diverse fasi di lavoro, ciascuna che produce una PR separata.
• Work Chain - Eseguono issue diverse attraverso un singolo workflow. Ogni elemento della work chain è un task diverso, tutti elaborati attraverso la stessa pipeline. Usate per elaborare in batch un backlog di issue tramite una coda automatizzata.

Modello dati delle Sprint Chain

Un record di sprint chain cattura l’intera configurazione e lo stato di runtime dell’esecuzione batch:

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

L’array sprintPrUrls è allineato per indice alla sequenza di sprint. sprintPrUrls[0] contiene la PR dello sprint 1, sprintPrUrls[1] quella dello sprint 2, e così via. Gli sprint non ancora completati hanno undefined al loro indice.

Creare una Sprint Chain

Le sprint chain vengono create e gestite dalla pagina Runs (/p/[id]/runs) usando lo sprint chain launcher.

Ciclo di vita dell’esecuzione

L’orchestratore di sprint chain gestisce l’esecuzione attraverso tutti gli sprint. Il ciclo di vita segue un pattern strettamente sequenziale:

Transizioni di status della chain

• pending - La chain è stata creata ma il primo sprint non è partito. È uno stato transitorio breve.
• running - Uno sprint è attivamente in esecuzione. Il campo currentSprintIndex riflette quale sprint è in corso.
• completed - Tutti gli sprint si sono conclusi con successo. Ogni sprint ha prodotto un run e (se il codice è stato modificato) una pull request.
• failed - Uno sprint ha incontrato un errore irrecuperabile che ha impedito alla chain di continuare. Il record della chain cattura quale sprint è fallito.
• cancelled - L’utente ha fermato manualmente la chain prima del completamento di tutti gli sprint.

Creazione di run per sprint

Per ogni sprint, l’orchestratore crea un record di workflow run standard con:

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

Quando il run dello sprint si completa e una PR viene creata, l’orchestratore della chain cattura l’URL della PR in sprintPrUrls all’indice dello sprint attuale, poi avanza currentSprintIndex e avvia lo sprint successivo.

Sequenziamento degli sprint

Gli sprint sono strettamente sequenziali - lo sprint 2 non parte finché il run dello sprint 1 non si è completato del tutto (status completed o failed). Questo garantisce che ogni sprint possa basarsi sulle modifiche di codice commitate dallo sprint precedente. La branch usata attraverso gli sprint è tipicamente la stessa branch di feature, così i commit di ogni sprint si impilano sul lavoro degli sprint precedenti.

Tracciamento delle PR per sprint

Una delle funzionalità chiave delle sprint chain è il tracciamento delle pull request per sprint. Ogni sprint che produce modifiche di codice crea la propria pull request. L’array sprintPrUrls registra questi URL, dandoti una traccia di audit completa di ciò che è stato consegnato in ogni fase di 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)
]

Gli URL di PR in sprintPrUrls vengono mostrati nella vista di dettaglio della sprint chain, dandoti link diretti per revisionare l’output di ogni sprint senza navigare nell’intera lista dei run.

Ripresa da uno sprint

Le sprint chain supportano una capacità di ripresa da uno sprint. Se una chain fallisce o viene annullata prima di completarsi, puoi riavviarla da uno sprint specifico anziché rieseguire l’intera sequenza.

Il campo resumeFromSprint del record della sprint chain controlla da quale indice di sprint l’orchestratore parte quando la chain viene ripresa. Impostare resumeFromSprint = 2 (indicizzato da zero) significa che la chain comincia allo sprint 3, saltando gli sprint 1 e 2.

Annullare una Sprint Chain

Puoi annullare una sprint chain in esecuzione in qualsiasi momento dalla vista di dettaglio della sprint chain. L’annullamento:

1. Imposta lo status della chain a cancelled.
2. Annulla il workflow run dello sprint in esecuzione se è ancora in corso.
3. Impedisce agli sprint successivi di partire.

Tutte le PR di sprint create prima dell’annullamento rimangono aperte in GitHub. Il lavoro commitato sulla branch è preservato e può essere ripreso usando la capacità di ripresa.

Casi d’uso

• Sviluppo di feature iterativo - Lo sprint 1 imposta lo scaffold del modello dati e dell’API, lo sprint 2 costruisce l’interfaccia, lo sprint 3 aggiunge i test, lo sprint 4 gestisce i casi limite. Ogni sprint produce una PR revisionabile.
• Migrazioni a fasi - Lo sprint 1 migra la libreria di componenti A, lo sprint 2 migra la libreria B, lo sprint 3 aggiorna tutti i consumatori. Ogni sprint è un’unità di modifica sicura e indipendente.
• Miglioramenti di qualità del codice in batch - Ogni sprint esegue lo stesso workflow di qualità su un modulo diverso della codebase, con prompt per sprint mirati a directory specifiche.
• Copertura di test incrementale - Sprint dopo sprint, un workflow aggiunge copertura di test a diverse aree, con ogni sprint mirato a un package o dominio di feature diverso.
• Aggiornamenti di dipendenze progressivi - Lo sprint 1 aggiorna un insieme di dipendenze, lo sprint 2 aggiorna il successivo, evitando una PR enorme con centinaia di conflitti.

Monitorare le Sprint Chain

Le sprint chain sono visibili in due posti:

• Lista dei Runs - I singoli run di sprint appaiono con source sprint. Usa il filtro di source per isolarli.
• Vista di dettaglio della sprint chain - Mostra lo status della chain, l’indice di sprint attuale, tutti gli URL di PR di sprint e una timeline delle esecuzioni di sprint. Accessibile dalla voce della chain nella navigazione della pagina Runs.

Le notifiche vengono inviate quando la chain si completa (sprint_completed) o fallisce (sprint_failed), così non devi monitorare attivamente l’esecuzione.