Un plan est un ensemble ordonné de tâches regroupées en phases. Vous l'approbationnez avant que le code ne soit écrit.
Utilisez-en un lorsque le travail nécessite plusieurs modifications dans un ordre précis, ou lorsque vous souhaitez voir l'ensemble de l'approche avant de vous engager dans quoi que ce soit.
Le cycle de vie
La planification constitue une étape à part entière, et non une simple transformation instantanée.
- La planification commence. L'architecte explore le code source et rédige les phases et les tâches.
- Vous examinez l'esquisse. C'est le point d'intervention le moins coûteux de tout le système.
- Approuver, réviser ou réinitialiser. Approuver le libère pour exécution ; réviser le renvoie avec vos commentaires ; réinitialiser relance la planification.
- Exécution. Les tâches s'exécutent dans l'ordre, en respectant les limites des phases.
Vous pouvez approuver et exécuter en une seule étape, ou approuver puis lancer l'exécution plus tard.
Réviser plutôt que réinitialiser
Lorsqu'un plan est presque correct, le réviser conserve ce que l'architecte a appris sur votre code source et applique vos commentaires. Réinitialiser efface ces éléments et recommence depuis le début.
Réinitialisez quand l'approche globale est erronée. Révisez quand l'approche est correcte mais que les détails le sont moins. La révision est bien moins coûteuse, et le contenu d'un plan rejeté n'est pas perdu : il sert d'entrée pour la tentative suivante.
Contrôler un plan en cours d'exécution
Un plan en cours peut être mis en pause, repris ou annulé, et vous pouvez suivre son avancement au sein de ses phases. Les plans peuvent également être clonés, ce qui constitue le moyen pratique de réutiliser une structure qui a fonctionné — par exemple, une migration appliquée à un second service.
Les plans terminés peuvent être archivés pour garder la vue active pertinente.
Une seule pull request, et non une par tâche
Les tâches d'un plan n'ouvrent pas chacune une pull request. Elles travaillent sur leurs propres branches et fusionnent dans une branche branche de voie; cette branche est promue sous forme de demande de fusion unique vers votre branche de base lorsque le travail est qualifié.
task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘Vous examinez donc la fonctionnalité assemblée en une seule fois, avec l'ensemble des modifications visibles, plutôt que d'approuver les phases inachevées une par une.
Les plans inter-projets constituent l'exception : une tâche appartenant à un projet différent de celui de la voie est promue séparément, ce qui donne une pull request par dépôt. Une pull request ne peut pas s'étendre sur deux dépôts.
Phases et parallélisme
Les phases définissent l'ordre, pas la concurrence. Les tâches au sein d'une phase peuvent s'exécuter en parallèle si la capacité le permet ; la phase suivante attend la fin de la phase courante.
Un plan comprenant dix tâches pouvant être exécutées en parallèle et un seul emplacement d'agent les exécutera toujours une par une. La structure ne crée pas de capacité — consultez Capacité et emplacements d'agents.
Plan ou tâche ?
Vous décidez en choisissant Plan de travail par phases ou Une tâche exécutable lors de l'étape de routage. Aucun élément n'analyse votre demande et ne décide à votre place.
Le critère est la lisibilité lors de l'examen : une pull request qu'un collègue pourrait lire d'une traite constitue une tâche ; tout ce qui nécessite plusieurs modifications ordonnées forme un plan.
Opter pour une tâche alors que le travail est réellement important représente l'erreur la plus risquée : la tâche peut se heurter à une limite en cours de route, gaspillant ainsi l'exécution. Opter pour un plan coûte simplement une étape d'approbation dont vous n'aviez pas strictement besoin.
Portes de livraison
Un plan peut inclure une porte de livraison définissant les conditions à remplir avant que son résultat ne progresse. Consultez Porte de qualité.