Versions

L'usine transforme les tâches et les plans en demandes de fusion validées. Une fois fusionnées, une version répond à la question suivante : quelle partie de ce travail est en cours d'exécution où, et était-elle sûre à déployer ?

Une version fixe un commit Git précis et le suit à travers vos environnements, comme par exemple la phase de test puis la production. Ce commit peut déjà se trouver sur votre branche de déploiement, ou bien Coroid peut d'abord regrouper les pull requests ouvertes en un seul pull request de version dont le commit de fusion devient la version. À chaque étape, Coroid vérifie le commit, recueille les approbations que vous avez demandées et enregistre le déploiement signalé par votre CI/CD. Coroid ne marque jamais une version comme déployée sur la base de ses propres indications. Votre pipeline ou une personne effectuant un enregistrement de déploiement externe doit confirmer ce déploiement.

En résumé en une minute#

• Version: un commit, un nom et une version optionnelle. Une version telle que 2.4.0 est optionnelle, afin que la livraison continue fonctionne sans étiquettes.
• Environnement: une étape sur le chemin menant à vos utilisateurs, comme Staging ou Production. Chaque projet définit ses propres étapes et leur ordre.
• Déploiement: les environnements que la version a déjà atteints.
• Travail: les tâches prévues 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éploiement et état de santé. La page de la version ouvre toujours l'étape qui nécessite votre intervention.
• Regroupement: une version créée à partir de pull requests ouvertes. Coroid les fusionne dans une seule branche de version, selon un ordre que vous pouvez modifier, et ouvre un seul pull request de version. Une version groupée comporte une cinquième étape, Regroupement, avant les vérifications.

Consulter une version d'un coup d'œil#

Ouvrir Versions dans la barre latérale principale pour chaque projet, ou l'onglet Versions pour ce projet uniquement. La liste affiche l'avancement du travail de chaque version, son déploiement progressif dans les environnements et son état. 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. Sélectionner Exécuter les vérifications. Coroid applique le graphique de qualité de validation de la version du projet sur le commit exact et confirme que chaque modification liée fait bien 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 précisément ce qu'il en est. Modifier le commit ou les modifications liées rend les vérifications précédentes obsolètes ; l'étape vous demande alors de les exécuter à nouveau.

Approbation. Une fois les vérifications réussies, les personnes autorisées selon vos règles peuvent procéder à l'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é aux Actions GitHub ou à GitLab CI/CD pour cet environnement, un Propriétaire ou un Administrateur sélectionne Déployer vers… et Coroid lance alors le pipeline pour ce commit exact. Dans le cas contraire, votre pipeline se charge du déploiement et en rend compte. Dans tous les cas, l'étape ne devient verte qu'après confirmation du succès.

État de santé. Après un déploiement réussi, Coroid applique le graphique de qualité canary du projet si vous en avez un. Un résultat positif indique que l'environnement est sain. Un résultat négatif signale Nécessite une intervention et propose une solution de récupération. En l'absence de canary, l'état de santé reste inconnu au lieu d'être considéré comme sain par défaut.

Signification des états#

Prêt « Prêt » ne signifie jamais déployé. Seul un déploiement confirmé permet d'avancer la version sur la trajectoire de déploiement.

Workflows#

Configurer les versions pour un projet#

À faire une fois par projet. Ouvrez Versions, sélectionnez Paramètres de version, puis choisissez le projet.

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

2. Dans Règles d'approbation, publiez les 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 les vérifications tant que les règles ne sont pas 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 l'origine de la version de chaque version et attribuez à chaque environnement une URL de version afin que Coroid puisse confirmer ce qui y est exécuté.

Paramètres de version Guide vous à travers chaque écran, et Intégrer la version dans votre build Explique comment la version parvient à votre application.

Livrer le travail planifié#

À utiliser lorsque vous savez à l'avance ce qui doit être livré ensemble.

1. Créez la version en avance, avant qu'un commit ne soit défini. Elle démarre sous forme de 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 se 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 fusioné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 nombreuses pull requests sont en attente, provenant de Coroid ou de votre équipe, et qu'elles doivent être publiées ensemble.

1. Sélectionnez Nouvelle publication, choisissez le projet, puis sélectionnez Pull requests ouvertes. Cette option nécessite un dépôt GitHub ou GitLab ; les projets hébergés par Coroid publient donc un commit.
2. Coroid répertorie les pull requests ouvertes vers la branche de déploiement, en commençant par les plus sûres. Une pull request ouverte par Coroid apparaît sous la forme de sa tâche ou de son plan. Coroid tient compte des informations déjà connues du fournisseur et de sa propre revue : vérifications, revues, taille, conflits et fichiers modifiés par plusieurs pull requests. Il exclut les brouillons, les vérifications en échec, les modifications demandées et les pull requests provenant de forks, et en indique la raison.
3. Décochez les éléments à reporter et utilisez les flèches pour modifier l'ordre. Une demande de fusion qui s'appuie sur une autre (une pull request en cascade ou indiquant « depends on #12 ») apparaît toujours après celle-ci.
4. Sélectionnez Créer une publication. Coroid crée release/<version> depuis la branche de déploiement, fusionne les pull requests dans l'ordre prévu et ouvre un seul pull request de version qui liste et lie chacune d'entre elles.
5. Si un conflit survient entre pull request et la branche de version, le Regroupement étape s'arrête là et affiche les fichiers. Sélectionnez Résoudre avec Coroid pour permettre à l'agent développeur de fusionner le tout et de résoudre le conflit dans une tâche, ou L'ignorer pour continuer sans ce fichier.
6. Examinez le pull request de version et fusionnez-le avec un commit de fusion. Votre fournisseur marque ensuite chaque élément pull request regroupé comme étant fusionné. Coroid fixe alors le commit de fusion en tant que commit de version, enregistre les pull requests groupées comme étant celles qui sont livrées, et ferme celles qui restent ouvertes en y ajoutant un lien vers le pull request de version.
7. Suivez les quatre étapes pour chaque environnement comme d'habitude.

Les fusions par regroupement ou réorganisation fonctionnent également, mais les pull requests d'origine ne sont pas marquées comme fusionnées par votre fournisseur. Coroid les ferme alors avec un commentaire.

Livrer ce qui se trouve sur la branche principale#

À utiliser 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 sans consulter Coroid, il peut néanmoins signaler chaque déploiement. Lorsqu'aucune version n'existe pour un commit signalé, Coroid crée une version observée pour celui-ci, clairement marquée comme n'ayant pas passé les vérifications de Coroid.

Livrer une correction urgente#

Un Propriétaire ou Administrateur peut activer Il s'agit d'une correction urgente lors de la création d'une version, définissez le commit complet de la correction et indiquez pourquoi le calendrier normal ne convient pas. Les corrections urgentes suivent les règles de correction urgente de chaque environnement, qui peuvent exiger moins d'approbations. Les vérifications de qualité et les éléments de liste de contrôle restent obligatoires, et seuls les Propriétaires et Administrateurs approuvent les corrections urgentes.

Se remettre d'une panne#

Si l'étape de santé affiche Nécessite une intervention, ouvrez État de santé sur l'environnement concerné et sélectionnez un commit stable antérieur pour le redéployer. Restauration et trains de déploiement couvre les options disponibles, y compris les pipelines incapables de fournir des retours.

Depuis le Chat ou votre éditeur#

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

Déployer plusieurs projets simultanément#

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

Ce que Coroid fait et ne fait pas#

• Coroid définit, 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 pour vous.
• Coroid lance un pipeline uniquement lorsque vous en avez connecté un et qu'un Propriétaire ou 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 éditez 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 CI
• Incorporer la version dans votre build
• Restauration et trains de déploiement
• Sprints
• Tâches, plans, Sprints et catégories
• Preuves de qualité et d'examen