Revue et promotion

Environnements persistants et CI & Review

Créez des environnements partagés de longue durée, configurez les routes de revue CI, examinez les événements de merge avec des preuves d’assurance qualité, fusionnez dans Console et promouvez le candidat validé.

Administrateurs clientMembres clientOpérateurs de plateforme

Dernière mise à jour 26 septembre 2026

Environments (/environments) et CI & Review (/ci-review) sont les workflows de validation partagés de Console. Utilisez-les lorsqu’une équipe a besoin d’un environnement d’exécution durable pour la QA, l’UAT, les démonstrations, la préproduction ou la revue client, et souhaite que les modifications passent par la revue de code et la QA avant leur promotion.

Un environnement persistant n’est pas un espace de travail personnel. C’est un environnement d’exécution partagé par l’équipe, avec sa propre stratégie, sa facturation et son historique d’événements. Un profil d’espace de travail CI indique à Console quel environnement de revue ou de QA utiliser lorsqu’un événement de merge nécessite des vérifications dans un navigateur, une base de données ou un outil d’analyse du code.

Qui peut y accéder

Les deux pages se trouvent sous Livrer dans la navigation et sont accessibles à toute personne ayant une équipe : membres et administrateurs d’équipe, opérateurs et administrateurs de plateforme. La stratégie de votre équipe détermine qui peut créer des environnements et des profils CI. Si un bouton de création est absent ou que l’action est refusée, demandez à un administrateur d’équipe.

Avant de commencer

• Connectez le fournisseur Git du dépôt (Paramètres → Accès Git).
• Préparez une sauvegarde de base de données approuvée pour l’initialisation (Sauvegardes).
• Déterminez si la route vérifie uniquement la branche source ou cible aussi un environnement persistant. Ce choix modifie les vérifications exécutées.

Environnements persistants

Persistent Environments (« Créer et exploiter des espaces de travail persistants pour les environnements d’équipe ») répertorie les environnements de l’équipe avec leur file d’attente, leurs détails et leur inspecteur. Le bouton (i) à côté du titre explique la page et renvoie ici.

Créer un environnement persistant

Choisissez Create environment (/environments/new). L’assistant comporte quatre étapes — Source, Durée d’exécution, Politique et Vérifier — ainsi qu’un panneau de lancement qui répertorie les blocages éventuels.

1. Source : l’équipe, le nom de l’environnement, l’URL du dépôt et la branche source. Console vérifie l’accès au fournisseur. Activez la pile de dépôts lorsque le dépôt d’exécution et le dépôt du produit doivent être récupérés dans un ordre précis.
2. Durée d’exécution : le profil d’environnement persistant, la famille de modèles, la cible de l’espace de travail et sa taille. Le profil définit la version de WebCentral (Java, Gradle, Tomcat et l’ensemble de licences).
3. Politique : la sauvegarde d’initialisation, l’exposition et le moteur de migration de base de données (Flyway, ARCHIBUS DUW ou aucun).
4. Vérifier : examinez le plan, puis choisissez Create environment. Le tarif de disponibilité pour la durée choisie est indiqué ici.

Console crée l’enregistrement et démarre l’espace de travail sous-jacent. L’environnement affiche ensuite son espace de travail persistant, le candidat et les versions actuelles, l’état de mise à jour, les raccourcis d’exécution et l’historique des événements. Toute personne qui peut voir l’environnement peut le renommer avec l’icône en forme de crayon. Le renommage ne modifie que le nom affiché.

Raccourcis d’exécution

Mettre à jour un environnement en deux étapes

Un environnement partagé n’est jamais redémarré par inadvertance :

1. Request environment update approuve la mise à jour, mais ne touche pas encore à l’environnement en cours d’exécution.
2. Start environment update la lance et attend la fin du processus. L’état passe à « en cours d’exécution », puis à « appliqué ».

CI & Review

CI & Review (« Parcourir les événements de merge, de l’admission à l’approbation, à la QA de l’espace de travail, à la validation de l’environnement cible et à la fusion par une personne ») sert à examiner et fusionner les modifications. Le bouton (i) à côté du titre explique la page et renvoie ici.

Une barre de workflow présente les étapes de l’événement de merge sélectionné : Admission, Revue, QA, Target QA et Merge. Cinq onglets avec leur nombre d’éléments se trouvent en dessous :

Créer un profil d’espace de travail CI

Choisissez Create CI profile (/ci-review/workspaces/new). Les étapes sont Source route, Exécution de l’espace de travail, Run policy et Review and create.

1. Source route : équipe, fournisseur, dépôt, branche et, éventuellement, environnement cible. La sélection d’un environnement cible active la vérification de la destination.
2. Exécution de l’espace de travail : revue, QA, revue et QA, ou QA de destination, ainsi que le modèle CI, la cible et la taille.
3. Run policy : conservation, artefacts, étapes à exécuter, portée de la QA, moteur de migration, profil de version WebCentral et sauvegarde de base de données.
4. Review and create : vérifiez le tableau, puis choisissez Create CI profile.

Un profil est une métadonnée de route, et non un espace de travail personnel. Console l’utilise lorsqu’un événement de merge nécessite une revue ou une QA dans un espace de travail.

Configurer le transfert au fournisseur

Dans Provider handoff, chargez une route, puis :

• Enregistrez une connexion gérée en utilisant une référence d’identifiant approuvée. Console n’affiche un aperçu qu’après l’enregistrement.
• Rotate credential ou Revoke credential.
• Install webhook, Reconcile webhook ou Remove webhook.
• Check connection avant d’utiliser la route.

Ne placez jamais de jetons fournisseur dans les noms de route, les descriptions ou les notes QA.

Revue d’implémentation

La revue d’implémentation transforme une modification planifiée — souvent un ticket approuvé dans Conception — en code fusionné :

1. Un développeur implémente le ticket dans un espace de travail et pousse une branche.
2. La modification apparaît dans Merge events, depuis le webhook du fournisseur, un transfert d’espace de travail ou un enregistrement manuel.
3. Dans Revue, vérifiez les branches source et cible, le lien du fournisseur, les personnes chargées de la revue et les modifications empilées. Attribuez les réviseurs et ajoutez des notes.
4. Choisissez Start review & QA. La revue ArchiBot examine le code, les différences empilées, les tests manquants et les chemins à risque. La QA du runner recueille des preuves d’exécution : tests rapides du navigateur, vérifications de base de données, commandes de test et journaux de l’espace de travail. Voir Bots Console.
5. Suivez la barre de workflow et Run detail. Utilisez Annuler l’exécution pour arrêter une exécution.

Merge in Console n’est disponible que lorsque :

• l’approbation d’un réviseur a été enregistrée ;
• la revue de code demandée a réussi ;
• la QA du runner demandée a réussi ;
• si un environnement cible est sélectionné, la vérification de cet environnement a réussi.

La fusion par une personne est le comportement par défaut. Après la fusion, le candidat peut être promu : utilisez Promote candidate dans Environnements lorsque la dernière exécution correspond au candidat, puis appliquez la mise à jour en deux étapes décrite plus haut.

Branche source uniquement ou environnement cible

Sans environnement cible, Console exécute la revue de code et la QA du runner, et Target QA est indiquée comme ignorée. Avec un environnement cible, Console valide également le candidat par rapport à la base de données, à la sauvegarde, au moteur de migration, à la cible, au modèle, à la chaîne d’outils et aux paramètres de cet environnement avant la fusion ou la promotion. Utilisez le même profil de version WebCentral pour l’environnement et pour les deux profils QA.

Journaux et preuves

Enregistrer dans Shared Drive conserve les preuves au-delà de la durée normale de conservation des journaux. Un lecteur inscriptible est nécessaire. Avant la fusion, les réviseurs doivent pouvoir déterminer dans Console ce qui a changé, quelles vérifications ont été exécutées et où se trouvent les preuves expurgées des données sensibles. Ne partagez jamais de clés, de jetons fournisseur, de cookies, de secrets de cluster, d’URL de base de données, de contenu de sauvegarde ou de fichiers de licence.

Sur un téléphone

• Environments empile la file d’attente, les détails et l’inspecteur. La sélection d’un environnement fait défiler l’écran jusqu’à ses détails.
• Create environment et Create CI profile restent fixés en bas de l’écran pendant leurs assistants. Les boutons en double du panneau de lancement et de la carte de vérification sont masqués pour qu’il n’y ait qu’un seul bouton principal.
• Le tableau des fournisseurs CI dans l’assistant de profil devient une série de cartes avec libellés.
• Les onglets CI & Review défilent horizontalement et les liens des réviseurs, des exécutions et des demandes de merge ont des zones tactiles de taille standard.
• Journaux de compilation et les autres boîtes de dialogue s’ouvrent sous forme de panneaux pleine largeur. La fenêtre contextuelle (i) à côté de chaque titre s’adapte à l’écran.

Dépannage

Pour obtenir de l’aide, indiquez l’équipe, le nom de l’environnement, l’événement de merge ou l’ID d’exécution, les branches, l’étape bloquée et un message d’erreur expurgé des données sensibles. Voir Transmission au support.

Guides associés

• Conception
• Bots Console
• Centre des opérations
• Shared Drive