Versions

L'outil transforme les tâches et les plans en pull requests validées. Une fois qu'elles sont fusionnées, un version répond à la question suivante : quel travail est exécuté où, et était-il sûr d'être déployé là ?

Une version épingle un commit Git précis et le suit dans vos environnements, par exemple Staging puis Production. Le commit peut déjà se trouver sur votre branche de déploiement, ou Coroid peut d’abord regrouper les pull requests ouvertes en une seule pull request de version, dont le commit de fusion devient la version. À chaque étape, Coroid vérifie le commit, recueille les approbations que vous demandez et consigne le déploiement signalé par votre CI/CD. Coroid ne déclare jamais une version déployée de sa propre initiative. Votre pipeline, ou une personne qui consigne un déploiement externe, doit le confirmer.

En résumé en une minute#

• Version: un commit, un nom et une version optionnelle. Une version comme 2.4.0 est optionnelle, ce qui permet la livraison continue sans étiquettes.
• Environnement: une étape sur le chemin vers vos utilisateurs, comme Staging ou Production. Chaque projet définit ses propres étapes et leur ordre.
• Déploiement progressif: les environnements que la version a déjà atteints.
• Travail: les tâches planifiées pour la version et les modifications fusionnées qu'elle contient, affichées sous forme de tâches terminées sur le total.
• Quatre étapes par environnement: Vérifications, approbation, Déployer et état de santé. La page de version ouvre toujours l'étape qui nécessite votre intervention.
• Regroupement: une version créée à partir de pull requests ouvertes. Coroid les fusionne en une seule branche de version, dans un ordre que vous pouvez modifier, et ouvre un pull request de version. Une version groupée possède une cinquième étape, Regroupement, avant les Vérifications.

Consulter une version en un coup d'œil#

Ouvrir Versions dans la barre latérale principale pour chaque projet, ou l'onglet Versions pour ce projet uniquement. En cours d'exécution, en haut de la page, affiche la version exécutée dans chaque environnement, depuis son dernier déploiement confirmé, ainsi que la personne ayant initié le processus. La liste montre l'avancement du travail de chaque version, son déploiement progressif dans les environnements et son statut. Utilisez les onglets pour basculer entre les versions en cours, livrées ou closes.

Sélectionnez une version pour ouvrir sa page.

La piste de déploiement progressif sert également de sélecteur. Sélectionnez un environnement pour voir ses quatre étapes. La page s'ouvre sur le premier environnement que la version n'a pas encore atteint, afin que l'action à entreprendre suivante soit déjà visible.

Les quatre étapes dans chaque environnement#

Vérifications. Choisissez Exécuter les vérifications. Coroid applique le graphe de qualité de validation de version du projet au commit précis et confirme que chaque modification liée fait partie de ce commit. Les éléments de liste de contrôle requis pour l'environnement doivent également être marqués comme terminés. Si quelque chose bloque la version, l'étape indique ce qu'il en est. Modifier le commit ou les modifications liées rend les vérifications précédentes obsolètes, et l'étape vous invite à les relancer.

Approbation. Une fois les vérifications réussies, les personnes autorisées selon vos règles peuvent donner leur approbation. L'étape indique le nombre d'approbations nécessaires et les rôles concernés. Si vos règles exigent des notes de version approuvées, celles-ci sont également approuvées ici.

Déployer. Lorsque les vérifications et l'approbation sont terminées, la version est prête pour l'environnement. Si Coroid est connecté à GitHub Actions ou à GitLab CI/CD pour cet environnement, un Propriétaire ou un Administrateur choisit Déployer vers… et Coroid lance le pipeline pour ce commit précis. Sinon, votre pipeline se déploie automatiquement et envoie une confirmation. Dans tous les cas, l'étape ne devient verte qu'après confirmation de la réussite.

État de santé. Après un déploiement réussi, Coroid exécute le graphe de qualité canari du projet si vous en avez un. Un résultat positif indique que l'environnement est sain. Un résultat négatif affiche Nécessite une intervention et propose une solution de récupération. En l'absence de graphe canari, l'état de santé reste inconnu plutôt que d'être considéré comme sain par défaut.

Signification des statuts#

Prêt Un pull request de version ne signifie jamais qu'il est déployé. Seul un déploiement confirmé permet d'avancer la version sur la piste de déploiement.

Workflows#

Configurer les versions pour un projet#

Faites cela une fois par projet. Ouvrez Versions, sélectionnez Paramètres de version, et choisissez le projet.

1. Dans Environnements, ajoutez vos étapes et ordonnez-les, par exemple Staging avant Production.

2. Dans Règles d'approbation, publiez des règles pour chaque environnement : nombre d'approbations requises, rôles concernés et éléments de liste de contrôle. Un environnement ne peut pas passer ses vérifications tant que les règles n'ont pas été publiées.

3. Dans Pipeline de déploiement, choisissez si c'est Coroid qui lance les déploiements ou votre pipeline. Ensuite, créez un jeton de rapport afin que votre CI/CD puisse indiquer à Coroid ce qui a été déployé.

4. Dans Gestion des versions, choisissez d'où provient la version de chaque release, et donnez à chaque environnement une URL de version afin que Coroid puisse confirmer ce qui y est exécuté.

Paramètres de version vous guide dans chaque écran, et Ajoutez la version à votre build montre comment la version atteint votre application.

Livrer le travail planifié#

Utilisez cette option lorsque vous savez à l'avance ce qui doit être livré ensemble.

1. Créez la version en avance, avant qu'un commit ne soit verrouillé. Elle démarre en tant que brouillon.
2. Définissez la version cible pour les tâches que vous souhaitez y inclure. Elles apparaissent sous Tâches planifiées, et la barre de progression s'remplit à mesure qu'elles sont terminées.
3. Une fois le travail fusionné, sélectionnez Modifier les détails et choisissez le commit à livrer. Coroid confirme quels changements fusionnés ce commit contient.
4. Suivez les quatre étapes pour votre premier environnement, puis pour le suivant.

Regrouper les pull requests ouverts#

Utilisez cette option lorsque de nombreux pull requests attendent, provenant de Coroid ou de votre équipe, et qu'ils doivent être livrés ensemble.

1. Sélectionnez Nouvelle version, choisissez le projet, et sélectionnez Pull requests ouverts. Cette option nécessite un dépôt GitHub ou GitLab, donc les projets hébergés par Coroid livrent un commit à la place.
2. Coroid liste les pull requests ouverts dans la branche de déploiement, en commençant par les plus sûrs. Un pull request ouvert par Coroid apparaît comme sa tâche ou son plan. Coroid évalue ce que le fournisseur et ses propres revues connaissent déjà : vérifications, revues, taille, conflits et fichiers touchés par plusieurs pull requests. Il ignore les brouillons, les vérifications échouées, les modifications demandées et les pull requests en provenance de forks, et indique pourquoi.
3. Décochez ce qui doit attendre, et utilisez les flèches pour modifier l'ordre. Un pull request qui dépend d'un autre (un pull request empilé, ou un qui indique « depends on #12 ») vient toujours après celui-ci.
4. Sélectionnez Créer une version. Coroid crée release/<version> à partir de la branche de déploiement, fusionne les pull requests dans l'ordre, et ouvre un pull request de version qui liste et lie chacun d'eux.
5. Si un pull request entre en conflit avec la branche de version, l' Regroupement étape s'arrête là et affiche les fichiers. Sélectionnez Résoudre avec Coroid pour permettre à l'agent développeur de le fusionner et de résoudre le conflit dans une tâche, ou L'exclure pour continuer sans lui.
6. Examinez le pull request de version et fusionnez-le avec un commit de fusion. Votre fournisseur marque ensuite tous les pull request regroupés comme fusionnés. Coroid verrouille le commit de fusion comme commit de version, enregistre les pull requests regroupés comme ce qui est livré, et ferme ceux qui sont encore ouverts avec un lien vers le pull request de version.
7. Suivez les quatre étapes pour chaque environnement comme d'habitude.

Les fusions type squash ou rebase fonctionnent également, mais les pull requests originaux ne sont pas marqués comme fusionnés par votre fournisseur. Coroid les ferme alors avec un commentaire.

Livrer ce qui se trouve sur la branche principale#

Utilisez cette option pour la livraison continue, lorsque vous livrez tout ce qui a été fusionné.

1. Sélectionnez Nouvelle version et choisissez le commit, généralement le dernier de la branche de déploiement.
2. Sous Comparer avec, sélectionnez l'environnement que vous allez remplacer. Coroid liste les pull requests et commits entre ce qui y est exécuté et votre commit, et sélectionne ceux qu'il peut vérifier.
3. Laissez le nom et la version vides si vous le souhaitez. Coroid nomme la version à partir de la date et du commit court, et la source de version du projet complète la version. Chaque version reçoit également le numéro de build suivant.
4. Créez la version et suivez les quatre étapes.

Si votre pipeline déploie à chaque fusion ou si quelqu'un effectue un déploiement manuel sans demander à Coroid, celui-ci peut tout de même enregistrer chaque déploiement. Lorsqu'aucune version n'existe pour une validation signalée, Coroid crée une version observée pour celle-ci, clairement identifiée comme n'ayant pas passé les vérifications de Coroid. Il récupère la version indiquée par le pipeline ou, lorsque Coroid attribue les versions du projet, la suivante (1.4.1 après 1.4.0), ainsi que le numéro de build suivant.

Envoyer une correction urgente#

Un Propriétaire ou un Administrateur peut activer Il s'agit d'une correction rapide lors de la création d'une version : fixez la validation complète de la correction et indiquez pourquoi le calendrier normal ne convient pas. Les corrections rapides suivent les règles propres à chaque environnement, qui peuvent exiger moins d'approbations. Les contrôles de qualité et les éléments de liste de vérification requis restent applicables, et seuls les Propriétaires et les Administrateurs approuvent les corrections rapides.

Se remettre en marche en cas de panne#

Si l'étape de santé indique Nécessite une intervention, ouvrez Santé sur l'environnement concerné et sélectionnez une validation saine antérieure pour la redéployer. Restauration et trains de versions décrit les options disponibles, y compris les pipelines incapables de renvoyer des informations.

Depuis le Chat ou votre éditeur#

L'assistant de Chat et le serveur MCP de Coroid disposent des mêmes outils de version : lister et inspecter les versions, choisir une validation, prévisualiser ce qui serait déployé, préparer une version, regrouper les pull requests ouverts, exécuter ses contrôles, l'approuver, demander un déploiement et rédiger des notes. Le regroupement, l'approbation et le déploiement nécessitent toujours la confirmation d'une personne. Consultez Assistant de Chat et Coroid en tant que serveur MCP.

Publier plusieurs projets ensemble#

Un train de versions regroupe les versions de plusieurs projets devant être publiés ensemble et dans l'ordre, comme un API et l'application qui en dépend. Consultez Restauration et trains de versions.

Ce que Coroid fait et ne fait pas#

• Coroid fige, vérifie et enregistre. Votre dépôt et CI/CD construisent et déploient.
• Lorsqu'il regroupe des pull requests, Coroid crée la branche de version et le pull request de version. Il ne fusionne jamais le pull request de version à votre place.
• Coroid lance un pipeline uniquement lorsque vous en avez configuré un et qu'un Propriétaire ou un Administrateur demande un déploiement.
• Une demande de déploiement ne constitue pas une preuve. La piste de déploiement n'avance que lorsque votre pipeline confirme le succès ou qu'une personne enregistre un déploiement externe vérifié.
• Les notes de version sont des brouillons que vous modifiez et approuvez. Coroid ne les publie nulle part.
• Un sprint est une période de planification, pas une limite de déploiement. Un sprint peut alimenter plusieurs versions, et une version peut contenir du travail issu de plusieurs sprints.

Articles associés#

• Paramètres de version
• Événements de déploiement et configuration de l'CI
• Intégrer la version dans votre build
• Restauration et trains de versions
• Sprints
• Tâches, plans, sprints et colonnes
• Qualité et preuves de révision