Coroid compte quatre unités de travail. Celles-ci sont imbriquées, et le choix de la bonne unité dépend principalement de la taille du travail et du nombre d'éléments devant être exécutés simultanément.
| Unité | Taille | Se termine par |
|---|---|---|
| Tâche | Une modification | Un seul pull request |
| Plan | Une fonctionnalité en plusieurs phases | Un seul pull request pour l'ensemble du plan |
| Sprint | Un bloc de travail sur une période donnée | Ce que produisent ses tâches |
| Voie | Un flux de travail parallèle | La branche dans laquelle le travail d'un plan est intégré |
Sprint · deux semaines
Phase 1
TâcheFormulaire de paiementTâcheValidation de la cartePhase 2
TâcheRécapitulatif de la commandeUne tâche isolée
TâcheCorriger l'analyse de la dateTâche
L'élément de base. Une tâche correspond à une unité de travail qui produit un seul pull request, et c'est elle qui est réellement exécutée — les plans, sprints et voies ne sont que des façons d'organiser les tâches.
Si vous pouvez décrire le résultat en un paragraphe et qu'un examinateur peut lire le résultat en une seule séance, il s'agit d'une tâche.
Plan
Lorsque le travail nécessite plusieurs modifications dans un ordre précis, il devient un plan : un ensemble ordonné de tâches regroupées en phases, que vous approuvez avant toute écriture de code.
Utilisez un plan dans les cas suivants :
- les étapes ultérieures dépendent des étapes précédentes
- vous souhaitez voir l'approche globale avant de vous engager dans quoi que ce soit
- le travail concerne une fonctionnalité plutôt qu'une simple modification
Approuver le plan constitue le point d'intervention le moins coûteux du système. Rejeter une approche à ce stade ne coûte qu'une minute ; le rejeter après l'exécution de trois tâches entraîne trois exécutions supplémentaires.
Comment un plan arrive dans votre dépôt
Les tâches d'un plan n'ouvrent pas chacune un pull request. Elles travaillent sur leurs propres branches et sont fusionnées dans une voie, et cette voie est promue en tant que unique demande de fusion vers votre branche de base.
Branche de voie
L'endroit où le travail du plan s'intègre
Une pull request
La fonctionnalité assemblée, examinée une fois
main
Votre branche de base
Une tâche destinée à un projet différent : la voie est promue isolément, donc un plan inter-projets ouvre une pull request par dépôt.
Ainsi, vous examinez la fonctionnalité assemblée en une seule fois, avec l'ensemble des modifications sous vos yeux, plutôt que d'approuver les phases inachevées individuellement.
L'exception concerne le travail s'étendant sur plusieurs projets : une tâche appartenant à un projet différent de celui sur lequel la voie est promue est traitée séparément, de sorte que les plans inter-projets génèrent un pull request par dépôt. C'est inévitable — un pull request ne peut pas s'étendre sur deux dépôts.
Sprint
Un conteneur à durée limitée pour le travail, avec ses propres métriques et chronologie. Les sprints répondent à la question « que faisons-nous pendant cette période et comment cela s'est-il déroulé » plutôt qu'à « comment cette fonctionnalité est-elle construite ».
Utilisez un sprint lorsque vous coordonnez le travail d'une équipe sur une période donnée. Utilisez un plan lorsque vous décomposez une fonctionnalité. Ce ne sont pas des alternatives — un sprint peut contenir des tâches appartenant à plusieurs plans.
Voie
Une voie est l'endroit où le travail parallèle d'un plan est intégré. Les tâches ciblent la branche de la voie plutôt que votre branche de base, afin que plusieurs agents puissent progresser simultanément sans entrer en conflit, et que le résultat assemblé soit promu en tant que unique pull request dès qu'il remplit les critères.
Alors qu'un plan porte sur l'ordre, une voie porte sur la concurrence et l'intégration. Si vous disposez de capacités pour plusieurs agents et d'un travail qui ne s'enchaîne pas strictement, la voie permet à ces éléments de s'exécuter ensemble tout en arrivant sous forme de modification pouvant être examinée.
Le choix
La question n'est pas le nombre de demandes de fusion souhaitées — qu'il s'agisse d'une tâche ou d'un plan, le résultat est identique. Il s'agit de savoir combien de travail doit être effectué avant que le résultat mérite d'être examiné.
- Cette modification est-elle suffisamment concise pour qu'un examinateur puisse la lire en une seule séance ? Oui → tâche.
- Nécessite-t-elle plusieurs modifications ordonnées avant d'avoir un sens global ? Oui → plan. Sa voie gère l'exécution des éléments en parallèle lorsque cela est possible.
Les sprints complètent tout cela en tant que couche de planification et de reporting.
Où s'inscrit la Version
Une Version constitue l'enregistrement de livraison après intégration, et non une tâche, un plan, un sprint ou une file d'attente supplémentaire. Elle associe un commit du dépôt, vérifie que le travail prévu figure dans ce commit, puis suit les tentatives de déploiement dans chaque environnement. Une version peut contenir du travail issu de plusieurs sprints ; un sprint peut générer plusieurs versions. La promotion dans une file d'attente ouvre un pull request mais ne crée pas à elle seule une livraison vérifiée.
Ce qui limite le nombre d'exécutions simultanées
Ce n'est pas la structure, mais la capacité. Un plan comprenant dix tâches pouvant être exécutées en parallèle et doté d'une seule emplacement d'agent les exécute une par une. Consultez Capacité et emplacements d'agent.