Les paramètres de version sont propres à chaque projet. Ouvrez Versions, puis sélectionnez Paramètres de version, et choisissez le projet. Il y a quatre écrans, chacun répond à une question.
- Environnements
- Où va une version ? Ajoutez des points d'arrêt et ordonnez-les.
- Règles d'approbation
- Quelles conditions doivent être remplies au préalable ? Approbations, rôles, liste de contrôle et règles de correctif urgent par environnement.
- Pipeline de déploiement
- Qui déploie et comment Coroid reçoit-il les retours ? Votre pipeline ou Coroid le lance ; un jeton de rapport permet à CI/CD de confirmer le résultat.
- Gestion des versions
- Quelle est cette version ? D'où proviennent les versions, ce que reçoit le build, et où Coroid vérifie ce qui est exécuté.
Seuls les Propriétaires et les Administrateurs peuvent modifier les paramètres de version. Tous les autres utilisateurs n'ont qu'une capacité de lecture. Il faut d'abord connecter un dépôt, car chaque version fait référence à un commit au sein de celui-ci.
Environnements
Où est déployée une version et dans quel ordre ?
Chaque projet commence par la production. Ajoutez les autres environnements de déploiement, comme le staging ou le QA, via l'option Ajouter un environnement. Attribuez un nom à chaque environnement. Coroid suggère d'utiliser une clé issue du nom, par exemple staging. Votre CI/CD utilise cette clé lorsqu'il génère un rapport de déploiement ; conservez-la stable dès que les pipelines l'utilisent.
Définissez l'ordre avec Vient après. L'environnement de staging qui vient après aucun autre et la production qui vient après le staging forment le chemin Staging › Production. La page de version affiche sa trajectoire de déploiement dans cet ordre, et les règles d'approbation peuvent exiger que l'étape précédente réussisse avant de passer à la suivante.
Règles d'approbation
Quelles conditions doivent être remplies avant qu'une version ne soit déployée ici ?
Sélectionnez l'environnement en haut. Les règles sont spécifiques à chaque environnement : le staging peut avoir des exigences moins strictes tandis que la production est plus rigoureuse.
- Approbations requises: le nombre de personnes différentes nécessaires pour approuver. Un nombre nul permet à une version d'être déployée dès que ses vérifications sont passées.
- Qui peut approuver: les rôles au sein de l'organisation autorisés à approuver.
- Séparer le demandeur et les approuveurs: la personne qui lance le déploiement ne peut pas l'approuver elle-même, et celle qui modifie les notes de version ne peut pas les approuver non plus.
- Les contrôles de qualité sont validés: toujours activé. Le graphique de qualité du projet avec un
release_validationLe déclencheur s'exécute sur le commit exact. Publiez ce graphique depuis les paramètres de qualité du projet. - D'abord l'environnement précédent: la version doit déjà être déployée dans l'environnement qui suit celui-ci.
- Notes de version approuvées: les notes actuelles nécessitent une approbation, et toute modification ultérieure requiert une nouvelle approbation.
- Liste de contrôle: étapes manuelles que quelqu'un confirme sur la page de version, comme « Migration de base de données vérifiée ». Marquez un élément comme obligatoire ou optionnel. Un élément obligatoire peut autoriser une exception temporaire. Le Propriétaire ou l'Administrateur enregistre une raison et une durée maximale de 24 heures ; l'exception ne s'applique qu'à ce commit et à cet environnement.
- Règles pour correctifs urgents: des règles plus souples pour les corrections urgentes : le nombre d'approbations ainsi que l'application des exigences liées à l'environnement précédent et à l'approbation des notes. Les contrôles de qualité et les éléments obligatoires de la liste de contrôle restent applicables, et seuls les Propriétaires et Administrateurs peuvent approuver les correctifs urgents.
Sélectionner Règles de publication pour enregistrer. La publication crée une nouvelle version des règles. Les approbations accordées sous l'ancienne version deviennent obsolètes ; une version en cours de déploiement demandera donc à nouveau une approbation. Un environnement sans règles publiées ne pourra pas passer ses contrôles, et l'écran l'indiquera.
Pipeline de déploiement
Qui lance un déploiement et comment Coroid prend-il connaissance du résultat ?
Sélectionnez l'environnement en haut, puis choisissez comment les déploiements démarrent :
- Mon pipeline se déploie automatiquement: conservez votre processus actuel. Coroid enregistre les déploiements lorsque votre CI/CD les signale, ou lorsqu'un Propriétaire ou Administrateur enregistre un déploiement externe sur la page de version.
- Coroid lance un workflow Actions de GitHub ou Coroid lance un pipeline GitLab CI/CD: affiché lorsque le dépôt du projet utilise ce fournisseur. Indiquez la branche ou l'étiquette pointant vers le commit de la version, le fichier de workflow pour GitHub, et le nom exact du job chargé du déploiement. Coroid vérifie la référence avant de lancer l'exécution et le job nommé avant d'accepter le succès.
Sous Rapports de déploiement, créez un jeton de rapport pour l'environnement et stockez-le en tant que secret dans votre CI/CD. Coroid affiche le jeton une seule fois et ne conserve que son hachage. Le remplacement du jeton désactive immédiatement l'ancien. La même écran affiche le point d'extrémité, l'identifiant du projet et la clé d'environnement dont votre pipeline a besoin, ainsi que la présence ou non de rapports. Événements de déploiement et configuration CI contient le format des événements et des exemples.
Gestion des versions
Quelle est la version de ce déploiement, et comment la build l'obtient-elle ?
Choisissez l'origine de la version de chaque déploiement : Coroid suggère la version suivante, Coroid la lit depuis un fichier dans le dépôt, ou votre pipeline la communique. Chaque déploiement reçoit également un numéro de build qui n'augmente qu'à la hausse. L'écran liste les valeurs que Coroid transmet à votre pipeline, permet d'ouvrir un Nouveau travail pour demander leur ajout à votre build, et prend en compte une URL de version par environnement afin que Coroid puisse vérifier ce qui est exécuté dans chacun d'eux. Intégrer la version dans votre build contient les détails et les recettes pour les builds web, serveur, Docker, iOS et Android.
Transférer les paramètres entre organisations
L'exportation et l'importation des paramètres incluent les environnements, leur ordre, la configuration du pipeline, la gestion des versions, les URLs de version et les règles publiées, y compris les règles de correctifs urgents. Les jetons de rapport et les numéros de build ne sont jamais exportés. Créez de nouveaux jetons après une importation ; chaque projet conserve ses propres numéros de build.