Comment une tâche se transforme en pull request

C'est la page de référence pour le reste de la documentation. Elle nomme chaque étape d'exécution afin que les autres articles puissent préciser où se déroule une action.

Le chemin#

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

Spécification#

Coroid ne commence pas par votre phrase. Il transforme d'abord votre description en spécification: ce qui sera construit, ce qui est explicitement hors périmètre, et les critères d'acceptation qui déterminent si le travail est réussi.

C'est essentiel car les critères d'acceptation servent de référence à l'étape de vérification plus tard. Une spécification floue entraîne un travail difficile à évaluer.

Vous pouvez consulter et modifier la spécification dans l'onglet Spécification avant le début de l'exécution.

Le guide de développement piloté par la spécification explique comment rédiger des critères testables, définir les limites du périmètre et maintenir la même définition du succès tout au long de la planification, de l'implémentation et de la révision.

Planifier#

Pour toute modification dépassant une petite modification, la spécification devient un plan: un ensemble ordonné d'étapes regroupées en phases. Vous approuvez le plan avant l'écriture du code.

Rejeter un plan est peu coûteux et constitue la bonne décision lorsque l'approche est erronée. Rejeter après l'écriture du code est coûteux. C'est à ce stade que votre jugement a le plus d'influence.

Construire#

Un agent clone le dépôt dans un espace de travail isolé et y travaille. Il lit le code, écrit la modification et met à jour ou crée les tests.

L'espace de travail est temporaire et associé à chaque tâche. Aucune action de l'agent n'affecte votre branche par défaut, et deux tâches exécutées simultanément ne peuvent pas accéder aux travaux en cours l'une de l'autre.

Vérifier#

Votre propre suite de tests s'exécute en premier — c'est le signal le plus fiable disponible, car elle reflète ce que votre équipe a déjà jugé important.

En complément, portes de qualité appliquent les configurations définies par votre organisation : seuils de couverture, analyse de code, scan de sécurité, tests navigateur sur une prévisualisation de déploiement. Une porte bloquante arrête la tâche ; une porte indicative enregistre une constatation et permet de continuer.

Révision#

Un agent réviseur analyse le diff comme le ferait un collègue et produit des constatations. Les constatations pouvant être corrigées sont renvoyées pour retravail ; les autres sont jointes à l'pull request afin que vous puissiez les voir.

C'est pourquoi une Coroid pull request arrive déjà révisée — non pour remplacer votre révision, mais pour que celle-ci ne soit pas la première.

Demande de fusion#

La branche est envoyée et une pull request est ouverte vers votre branche de base, contenant la modification, les tests, les résultats de vérification et les constatations de révision.

Coroid s'arrête ici. La fusion relève de votre responsabilité.

États des tâches#

L'état d'une tâche indique où elle se situe sur le parcours décrit ci-dessus :

Ce qui détermine le débit#

Un créneau d'agent exécute une tâche à la fois. Les créneaux définissent le niveau de parallélisme ; ils ne raccourcissent pas la durée d'une tâche individuelle. La durée d'une tâche dépend de la taille de la modification et du temps nécessaire à votre suite de tests.

Suivant#

Rôles des agents — quel agent gère quelle étape et quelles actions lui sont autorisées.