Plans

Un plan est un ensemble ordonné de tâches regroupées en phases. Vous l'approvez 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.

1. La planification commence. Une fois la demande qualifiée, l'architecte explore le code source et rédige les phases et les tâches. La planification démarre d'elle-même sauf si la demande comportait des pièces jointes ou utilisait le workflow SDLC ; dans ce cas, elle commence lorsque vous créez le plan ou terminez la préparation.
2. Vous examinez l'esquisse. C'est le point d'intervention le moins coûteux de tout le système.
3. Approuver, réviser ou réinitialiser. L'approbation le libère pour exécution ; la révision le renvoie avec vos commentaires ; la réinitialisation relance la planification.
4. Exécution. Les tâches s'exécutent dans l'ordre, en respectant les limites de phase.

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. La réinitialisation jette tout cela et recommence depuis le début.

Réinitialisez lorsque l'approche globale est erronée. Révisez lorsque l'approche est correcte mais que les détails ne le sont pas. La révision est beaucoup 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 contre votre branche de base lorsque le travail est validé.

Vous examinez donc la fonctionnalité assemblée en une seule fois, avec l'ensemble des modifications visibles, plutôt que d'approuver des 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, afin d'obtenir une pull request par dépôt. Une pull request ne peut pas s'étendre sur deux dépôts.

Lorsque la branche de base évolue#

Un plan peut s'exécuter pendant des heures, et votre équipe continue de fusionner des modifications dans la branche de base pendant ce temps. Le plan a été conçu, testé et examiné par rapport à la branche de base telle qu'elle était au moment du démarrage du plan. Au moment où son pull request est prêt, ce n'est peut-être plus la branche dans laquelle il sera fusionné.

Lorsqu'un plan commence à s'exécuter, Coroid enregistre la dernière validation de la branche de base comme référence. Avant que l'pull request du plan ne puisse fusionner, Coroid vérifie à nouveau la branche de base. Toute modification du contenu des fichiers compte, y compris pour les fichiers que le plan n'a jamais touchés. Un nouveau schéma d'authentification ou une règle de sécurité peut rendre un code correct incorrect sans provoquer de conflit de fusion, donc Coroid n'attend pas qu'un tel conflit survienne.

Si la branche de base a évolué, Approuver & fusionner reste désactivé et l'examen de promotion liste les nouvelles validations ainsi que les fichiers qu'elles ont modifiés. Vous choisissez ce qui doit se passer :

• Accepter la nouvelle branche principale (nommée d'après votre branche de base) — ces modifications n'affectent pas ce travail. Coroid enregistre qui a accepté quelle validation et pourquoi, et cette validation devient la nouvelle référence. Si la branche a encore évolué pendant que vous lisiez, Coroid refuse et vous affiche d'abord les validations plus récentes. Rien n'est accepté sans avoir été affiché.
• Fusionner et re-vérifier — Coroid fusionne la branche de base dans la branche de voie, en résolvant les conflits s'il y en a. Il fait ensuite passer la branche de voie par les étapes développeur, QA et réviseur, en la comparant aux critères d'acceptation du plan et aux validations en amont. L'approbation reste en attente jusqu'à la fin de ce processus. Ce n'est qu'alors que la nouvelle validation devient la référence. Si la fusion ou la re-vérification échoue, la décision vous revient.

La mise en pause est l'option par défaut. Un projet peut choisir Fusionner et re-vérifier à la place, afin que Coroid le lance sans attendre votre intervention ; consultez Paramètres du dépôt et de la branche. La re-vérification consomme des heures d'agent.

Si un plan est relancé depuis le début, une nouvelle ligne de base est enregistrée ; il s'exécute donc par rapport à la branche de base telle qu'elle est alors. Les preuves de la tentative précédente restent dans l'historique mais ne deviennent pas la base pour la nouvelle tentative.

Fusion forcée ignore également cette vérification et enregistre la raison écrite qui justifie ce choix. Voir Fusionner.

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 quand même une par une. La structure ne crée pas de capacité — consultez Capacité et emplacements d'agents.

Plan ou tâche ?#

Dans le formulaire Nouveau travail, choisissez Plan ou Tâche sous Créer en tant que, ou laissez-le sur Automatique et laissez la qualification décider. Un travail couvrant plusieurs projets devient toujours un plan. Si vous choisissez une option et que la qualification recommande l'autre, vous verrez cette recommandation avant toute création.

Le critère est la lisibilité lors de l'examen : une pull request qu'un collègue peut lire en une séance correspond à une tâche ; tout ce qui nécessite plusieurs modifications ordonnées constitue un plan.

Opter pour une tâche sur un travail réellement volumineux est l'erreur la plus risquée : la tâche peut épuiser son espace en cours de route, gaspillant ainsi l'exécution. Opter pour un plan vous 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é.

Articles associés#

• Tâches, plans, sprints et voies
• Sprints
• Spécifications
• Provenance