Une version regroupe les travaux livrés en un élément que vous pouvez nommer et décrire. Alors que les tâches, les plans et les sprints organisent le travail en cours, une version organise le travail déjà terminé.
Vous les trouverez sous Versions.
À quoi sert une version ?
Pour répondre à la question « Qu’a-t-on déployé ? » : pour les notes de version, pour les parties prenantes, ou pour votre propre historique des modifications.
Coroid suit le suivi du travail au niveau de la tâche, ce qui constitue la bonne granularité pour l'exécution mais la mauvaise pour la communication. Personne ne souhaite consulter une liste de quarante intitulés de tâches. Une version permet de rassembler tout cela en une seule déclaration cohérente.
Créer une version
Créez une version et associez-y les travaux livrés qui lui appartiennent. Le travail doit exister avant d'être inclus : une version décrit ce qui s'est passé, elle ne planifie pas ce qui va se produire.
Les versions et votre processus de déploiement
Une version Coroid est un simple enregistrement, et non un mécanisme de déploiement. Elle ne génère pas d'artefacts, ne tague pas votre dépôt ni n'envoie rien vers un environnement : votre pipeline existant s'occupe de tout cela lors des fusionnements, comme c'est déjà le cas.
Cette séparation est volontaire. Coroid ouvre des demandes de fusion ; ce qui se passe après leur fusion relève de votre processus. Introduire une seconde autorité de déploiement créerait précisément l'ambiguïté que vous souhaitez éviter le jour du déploiement.
Relation avec les sprints
Un sprint est une période ; une version est un déploiement. Ils coïncident souvent, mais pas systématiquement : le travail d'un sprint peut être déployé sur deux versions, et une version peut regrouper du travail issu de plusieurs sprints.
Utilisez celui que votre organisation utilise réellement pour communiquer. Recourir aux deux simplement parce qu'ils existent entraîne surtout une charge administrative inutile.