Coroid modélise un cycle de vie logiciel complet, pas seulement l'étape de construction. La plupart des processus s'exécutent automatiquement ; une partie correspond à un point de contrôle optionnel que vous activez lorsque le travail est suffisamment critique pour le justifier.
Le workflow SDLC optionnel
Dans le Nouveau travail formulaire, sous les paramètres avancés, se trouve une case à cocher :
Utiliser le workflow SDLC (optionnel) — pour examiner l'intention et les spécifications avant la planification. Désactivez cette option pour lancer directement la planification à partir de votre cahier des charges.
Il est désactivé par défaut. Lorsqu'il est désactivé, la planification commence à partir de votre cahier des charges après qu'il a passé la Qualification. Une fois activé, deux artefacts sont d'abord produits et approuvés :
- Intention — l'objectif réel du travail, avec les décisions et hypothèses qui le sous-tendent consignées par écrit.
- Spécification — périmètre, exclusions et critères d'acceptation.
La planification ne débute qu'une fois ces éléments approuvés.
Quand l'activer ?
Activez-le lorsque le coût de construire le mauvais produit est élevé, lorsque la demande provient d'une personne qui ne va pas examiner elle-même le plan, ou lorsque le cahier des charges contient une hypothèse que vous préféreriez voir consignée et approuvée par écrit.
Laissez-le désactivé si le cahier des charges est déjà sans ambiguïté. Un niveau d'approbation supplémentaire sur un travail routinier crée des frictions sans bénéfice réel — et l'étape d' approbation du plan reste applicable dans tous les cas.
Les cinq étapes
Le cycle de vie complet se déroule en cinq phases, chacune produisant des preuves utilisées par la phase suivante.
| Étape | Ce qui se passe | État |
|---|---|---|
| Définir | Une demande ambiguë se transforme en intention approuvée, décisions, hypothèses et critères de succès. | Version bêta |
| Visualiser | Concepts d'interface utilisateur optionnels, affinés et approuvés comme directives de conception. | Version bêta |
| Livrer | Le plan est décomposé et les agents l'exécutent. | Disponible |
| Démontrer | Les exigences correspondent aux tâches, aux vérifications, aux résultats d'inspection et aux modifications des demandes de fusion. | Disponible |
| Améliorer | Les moniteurs, les correctifs et les évaluations transforment les régressions en tâches pour le cycle suivant. | Disponible |
- DéfinirIntention approuvée, décisions, hypothèses et mesures de succèsBêta
- VisualiserConcepts d'interface utilisateur optionnels, approuvés comme directives de conceptionBêta
- LivrerLe plan est décomposé et les agents l'exécutentDisponible
- ProuverLes exigences correspondent aux tâches, aux vérifications, aux anomalies et aux changementsDisponible
- AméliorerLes régressions deviennent le travail du prochain cycleDisponible
OptionnelActivez le workflow SDLC pour valider l'intention et la spécification avant le début de la planification.
L'amélioration alimente le prochain cycle : les surveillances, remédiations et évaluations transforment les régressions en nouveau travail.
Définir et Visualiser sont actuellement en développement actif. Livrer, Démontrer et Améliorer fonctionnent déjà sur chaque tâche, que l'étape de validation soit activée ou non.
Pourquoi les artefacts sont versionnés
Les Approbations sont liées à une version précise d'un artefact. Modifier un artefact approuvé crée un nouveau brouillon au lieu de changer silencieusement ce qui avait été convenu.
C'est ce qui donne du sens à une approbation. Une approbation qui reste flottante — attachée à « la spécification » plutôt qu'à une version spécifique de celle-ci — valide tout ce que le document indique ultérieurement, ce qui ne constitue pas une véritable approbation.
Rôles d'approbation
Les responsabilités liées au produit, à la conception, à la technique, à la sécurité et aux versions peuvent être attribuées indépendamment ; ainsi, la personne approuvant les implications de sécurité n'est pas forcément celle qui approuve la portée.
Lignée des preuves
Le but de la production de preuves à chaque étape est de permettre de retracer un pull request terminé : ce changement met en œuvre cette tâche, issue de cette exigence, elle-même dérivée de cette intention approuvée.
Cette chaîne rend la livraison autonome auditable. Sans elle, vous avez du code fonctionnel mais aucune trace de la raison pour laquelle il correspond à ce que vous aviez demandé.
Du code inspecté à une version
pull request est le résultat du cycle de travail. Une fois que les règles de votre dépôt autorisent la fusion, une Version ancre un hachage de commit complet et enregistre les modifications qu'il contient. Sa porte de prêt à l'emploi évalue ce commit exact pour un environnement choisi. Les Approbations sont liées à l'instantané de cette porte ; modifier le candidat ou la politique invalide les décisions prises précédemment.
La demande de déploiement lance une tentative dans votre pipeline connecté. Un rappel du fournisseur ou une attestation manuelle enregistre ce qui a atteint l'environnement, et un canari post-déploiement enregistre la santé séparément. La tâche, pull request et Version ont donc des significations distinctes : un travail accompli ne prouve pas que le code est arrivé en production.
Relation avec les plans
Le workflow SDLC et les plans constituent des étapes de validation différentes :
- Le workflow SDLC approuve ce qui doit être construit, avant même qu'une approche n'existe.
- Le plan approuve comment il sera construit, avant même l'existence du code.
Vous pouvez utiliser l'un, l'autre, ou aucun des deux. Tous deux sont moins coûteux que de réviser un pull request terminé avec lequel vous êtes en désaccord.