Revue et automatisation

Environnements persistants et revue CI

Créez des environnements persistants partagés avec l'assistant en quatre étapes, configurez des profils d'espace de travail CI, examinez les événements de fusion dans les cinq onglets CI et promouvez les candidats validés depuis Console.

Administrateurs clientOpérateurs de plateforme

Dernière mise à jour 18 juin 2026

Les environnements persistants et la revue CI sont des flux de travail détenus par Console pour la validation partagée. Utilisez-les lorsqu’un client a besoin d’un environnement d’exécution de QA, UAT, démonstration, staging ou revue client de longue durée et souhaite que les modifications passent la revue de code et le QA avant d’être promues.

Ces flux de travail sont différents des espaces de travail personnels des développeurs. Un environnement persistant est un environnement d’exécution partagé du client avec politique, facturation, support et historique d’événements. Un profil d’espace de travail CI est un profil d’environnement d’exécution de revue ou de QA détenu par une route, que Console utilise lorsqu’un événement de fusion nécessite des vérifications de navigateur, de base de données, d’intelligence de code ou d’environnement de destination.

Les deux surfaces se trouvent dans le rail gauche de Console. Environnements détient les environnements d’exécution partagés et leurs candidats ; CI et revue détient les routes, les événements de fusion, les exécutions et le transfert vers le fournisseur. Les deux sont liés l’un à l’autre, de sorte que vous pouvez passer d’un environnement à son historique de revue sans perdre le contexte.

Avant de commencer

• Vous avez besoin d’un rôle d’administrateur client ou d’opérateur de plateforme pour créer des environnements et des profils CI.
• Le dépôt et la branche que vous prévoyez de valider doivent être accessibles via un fournisseur Git connecté. Consultez Configuration de l’administrateur client pour la connexion du fournisseur et Sauvegardes et sources de restauration pour les amorces de base de données.
• Décidez si la route est uniquement sur la branche source ou cible un environnement persistant, car ce choix change les vérifications qui s’exécutent.

Créer un environnement persistant

Ouvrez Environnements et sélectionnez Créer un environnement. Console ouvre un assistant en quatre étapes avec un rail d’étapes en haut : Source, Exécution, Politique et Revue. Un panneau de lancement en direct à droite affiche les sélections actuelles et répertorie les éléments requis qui bloquent encore.

1. Source. Choisissez la portée du client, nommez l’environnement et confirmez l’URL du dépôt et la branche source. Console vérifie l’accès du fournisseur ici. Lorsqu’une modification dépend de plusieurs dépôts, activez la pile de dépôts afin qu’un dépôt d’exécution et un dépôt de produit soient extraits dans l’ordre.
2. Exécution. Choisissez le profil d’environnement persistant, la famille de modèles, la cible d’espace de travail et la taille d’exécution. Le profil définit les hypothèses de version de WebCentral, y compris le bundle Java, Gradle, Tomcat et licence attendu pour l’espace de travail sous-jacent.
3. Politique. Définissez la source d’amorce (sauvegarde de base de données), l’exposition et le moteur de migration de base de données. Choisissez le moteur de migration qui correspond à la destination : Flyway, ARCHIBUS DUW ou migrations désactivées.
4. Revue. Confirmez le plan de lancement. La grille de revue résume le profil, le mode de dépôt, la taille et la sauvegarde de base de données. Lorsque tout ce qui est requis est présent, sélectionnez Créer un environnement.

Lorsque la création démarre, Console crée l’enregistrement de l’environnement et démarre l’espace de travail sous-jacent lorsque la cible sélectionnée le permet. La carte de l’environnement affiche alors l’espace de travail persistant, les versions candidate et actuelle, l’état de mise à jour de l’environnement, les raccourcis d’exécution et l’historique des événements.

Les environnements persistants sont conçus pour rester actifs plus longtemps que les espaces de travail de développement personnels. Choisissez délibérément la taille d’exécution et la durée de facturation, et utilisez l’historique des événements pour confirmer quand l’espace de travail sous-jacent, la route Tomcat, l’amorce de base de données et l’état de promotion sont prêts.

Utilisez le profil de version de WebCentral qui correspond au dépôt source ou au WAR, en particulier pour les versions plus anciennes de WebCentral qui nécessitent Tomcat 8.5 ou Tomcat 9 au lieu de la valeur par défaut actuelle. Consultez Préréglages d’espace de travail pour voir comment ces profils correspondent aux paramètres d’exécution.

Ouvrir les raccourcis d’exécution de l’environnement

Une fois l’espace de travail persistant existant, utilisez les actions de la carte de l’environnement :

Ne collez pas de journaux bruts dans les tickets de support. Partagez plutôt l’état visible, l’ID d’exécution, le nom de l’espace de travail, l’horodatage et le texte d’erreur nettoyé.

Mettre à jour un environnement d’exécution en deux étapes

Lorsqu’une version candidate est prête à atterrir sur l’environnement d’exécution persistant, Console utilise une mise à jour délibérée en deux étapes afin qu’un environnement partagé ne soit jamais redémarré par accident.

1. Demander la mise à jour de l’environnement. Cela approuve la mise à jour de l’espace de travail persistant et la marque comme demandée. Console indique que la mise à jour est prête à démarrer mais n’a pas encore touché à l’environnement en cours d’exécution.
2. Démarrer la mise à jour de l’environnement. Cela démarre la mise à jour de l’espace de travail persistant et attend le résultat d’exécution. Console fait passer l’état à en cours d’exécution, puis à appliqué une fois que l’environnement d’exécution persistant est sur la version promue.

La carte de l’environnement affiche l’état de mise à jour actuel et une brève description pour chaque étape, ainsi que des lignes de preuve d’exécution pour que vous puissiez confirmer ce qui a changé.

Créer un profil d’espace de travail CI

Ouvrez CI et revue et sélectionnez Créer un profil CI (c’est Créer CI/profil dans la barre d’actions supérieure). Console ouvre un assistant en quatre étapes avec la même forme de rail d’étapes : Source, Exécution, Politique et Revue, affichées dans la zone de travail comme Route source, Exécution de l’espace de travail, Politique d’exécution et Revoir et créer.

1. Route source. Choisissez le client, le fournisseur, le dépôt, la branche et un environnement cible facultatif. La sélection d’un environnement cible est ce qui active la vérification de destination plus tard. Appliquez un profil de pile de dépôts lorsque la modification nécessite un dépôt d’exécution plus un dépôt de produit ou de dépendance.
2. Exécution de l’espace de travail. Choisissez la forme de l’espace de travail : revue, QA, revue plus QA, ou QA de destination. Sélectionnez le modèle CI, la cible d’espace de travail et la taille.
3. Politique d’exécution. Définissez la rétention, les artefacts, les étapes qui s’exécutent, la portée du QA et le moteur de migration de base de données. Sélectionnez le profil de version de WebCentral et la sauvegarde de base de données. La revue utilise généralement un raisonnement élevé ; le QA utilise généralement un raisonnement faible après que les vérifications déterministes ont rassemblé des preuves.
4. Revoir et créer. Confirmez le profil de route dans la grille de revue, puis sélectionnez Créer un profil CI.

L’enregistrement d’un profil d’espace de travail CI ne crée pas d’espace de travail de développeur personnel. Il crée les métadonnées de route que Console utilise lorsqu’un événement de fusion ou une exécution de test nécessite un espace de travail de revue ou de QA. Les exécutions légères peuvent toujours utiliser l’exécuteur Console sans espace de travail lorsque les outils de navigateur, de base de données et d’intelligence de code ne sont pas requis.

Si la route n’a pas d’environnement cible persistant, Console peut toujours exécuter le QA de la branche source. La revue de code commence à partir d’un événement de fusion Console, d’une demande de tirage du fournisseur ou d’un diff explicite afin que les relecteurs voient l’ensemble réel de modifications et la barrière de fusion. La vérification de l’environnement de destination est ignorée car il n’y a pas de configuration d’environnement à valider.

Les cinq onglets de CI et revue

La zone de travail de CI et revue est organisée en cinq onglets au-dessus du panneau principal, chacun avec un compteur en direct :

Au-dessus des onglets, une bande de flux de travail affiche le pipeline d’étapes pour l’événement de fusion sélectionné : Réception, Revue, QA, QA cible et Fusion. Chaque étape affiche son propre état, comme ouverte, en attente, ignorée ou en attente de vérifications.

Branche source uniquement versus environnement cible

Les routes uniquement sur la branche source exécutent la revue de code et le QA d’exécuteur sans environnement persistant sélectionné. Dans ce mode, Console ignore intentionnellement la vérification de l’environnement cible, et l’étape QA cible s’affiche comme ignorée.

Les routes avec un environnement persistant sélectionné ajoutent une vérification de l’environnement cible. Une fois que la revue de code et le QA d’exécuteur passent, Console valide le candidat par rapport aux valeurs par défaut de l’environnement sélectionné avant que la fusion ou la promotion puisse se poursuivre.

La vérification de l’environnement cible utilise les valeurs par défaut de l’environnement qui comptent après la promotion, y compris le type de base de données, la sauvegarde de base de données, le moteur de migration, la cible d’espace de travail, le modèle, la chaîne d’outils, les paramètres d’espace de travail et le remplacement de licence lorsqu’il est configuré.

Lorsqu’une route utilise une version plus ancienne de WebCentral, conservez le même profil de version sur l’environnement persistant, le profil de QA source et le profil de QA de destination. Cela permet aux preuves de revue, aux tests de fumée du navigateur et à la vérification finale de promotion de s’exécuter sur les mêmes hypothèses d’exécution.

Configurer le transfert vers le fournisseur

Ouvrez l’onglet Transfert vers le fournisseur et chargez une route pour enregistrer ou vérifier la connexion au fournisseur managé. Console détient la couche de revue ; la connexion au fournisseur lui permet de publier des commentaires de revue et de QA, d’envoyer des retours d’état et de recevoir des événements de fusion.

Depuis cet onglet, vous pouvez :

• Enregistrer une connexion managée. Enregistrez l’application du fournisseur, le service hook ou une référence d’identifiant approuvée telle que token://..., k8s://secret/key, ou une référence OpenBao/Vault. Console peut également accepter un jeton de fournisseur à usage unique ou un mot de passe d’application et le stocker dans le stockage de jetons Console, un Kubernetes Secret ou OpenBao/Vault. Après l’enregistrement, Console n’affiche qu’un aperçu de l’identifiant.
• Faire pivoter l’identifiant. Utilisez Faire pivoter l’identifiant lorsqu’un jeton expire ou est remplacé. Exécutez une vérification de connexion par la suite.
• Révoquer l’identifiant. Utilisez Révoquer l’identifiant pour conserver l’enregistrement de connexion mais arrêter la publication jusqu’à ce qu’une nouvelle référence d’identifiant soit ajoutée.
• Installer ou réconcilier un webhook. Utilisez Installer le webhook pour que les mises à jour d’événements de fusion parviennent à Console, Réconcilier le webhook pour réparer un hook dérivé et Supprimer le webhook pour arrêter les événements. Enregistrez ou sélectionnez une route avant d’installer le webhook.
• Vérifier la connexion. Utilisez Vérifier la connexion pour confirmer l’état de santé avant de vous fier à la route pour la revue, l’état ou la publication de commentaires.

Un panneau de préparation parcourt les métadonnées de route, le service du fournisseur, la cible d’installation, la source de l’identifiant, les actions autorisées, l’enregistrement Console et la santé du fournisseur, afin que vous puissiez voir quelle étape manque encore.

Ne mettez pas de jetons de fournisseur, de charges utiles d’identifiants brutes ou de secrets de déploiement privés dans les noms de routes, les descriptions, les notes de QA ou les instructions de route.

Examiner un événement de fusion

Les événements de fusion sont l’unité de revue normale dans Console. Un événement de fusion peut provenir d’un webhook de fournisseur, d’un transfert d’espace de travail ou d’un enregistrement manuel dans Console.

1. Ouvrez CI et revue.
2. Choisissez l’événement de fusion dans l’onglet Événements de fusion.
3. Ouvrez Revue dans Console pour voir la branche source, la branche cible, le lien du fournisseur, les éléments de fonctionnalité, la liste des relecteurs et les modifications empilées.
4. Attribuez des relecteurs ou ajoutez un relecteur personnalisé, et mettez à jour les notes du relecteur.
5. Sélectionnez Démarrer la revue et le QA lorsque la route est prête.
6. Surveillez la bande de flux de travail : Réception, Revue, QA, QA cible et Fusion.

Lorsque des modifications empilées sont détectées, Console affiche l’aperçu de pile borné et le contexte par fichier qu’il peut afficher en toute sécurité. Utilisez les liens du fournisseur uniquement pour le contexte secondaire.

La revue Archibot et le QA d’exécuteur peuvent s’exécuter séparément ou ensemble. La revue se concentre sur le code, le contexte de diff empilé, les tests manquants, les chemins à risque et l’impact sur la documentation. Le QA se concentre sur les preuves d’exécution telles que les tests de fumée du navigateur, les vérifications de base de données, les commandes de test sélectionnées, la validation de la chaîne d’outils et les journaux d’espace de travail. Consultez Bots Console pour voir comment les bots de revue et de QA Archibot sont configurés.

Si une exécution doit s’arrêter, utilisez Annuler l’exécution sur l’exécution dans l’onglet Preuves et journaux. Console marque l’exécution comme annulée.

Fusionner et promouvoir

Console conserve la fusion humaine par défaut.

Avant que Fusionner dans Console soit disponible :

• Une approbation de relecteur doit être enregistrée.
• L’étape de revue de code demandée doit passer.
• L’étape de QA d’exécuteur demandée doit passer.
• Si un environnement cible est sélectionné, la vérification de l’environnement cible doit passer.

Une fois la fusion terminée, le candidat validé peut devenir un candidat à la promotion pour l’environnement persistant sélectionné. Utilisez Promouvoir le candidat depuis Environnements uniquement lorsque la dernière exécution CI et la vérification de l’environnement cible correspondent à la version candidate. Une fois promu, utilisez la mise à jour d’environnement en deux étapes décrite ci-dessus pour l’atterrir sur l’environnement d’exécution en cours.

Journaux, preuves et Shared Drive

CI et revue et Environnements conservent l’historique des événements dans Console. Utilisez la chronologie d’exécution dans l’onglet Preuves et journaux pour voir les changements d’étape, les noms de tâches, l’état de l’environnement cible et les lignes de journal nettoyées.

Utilisez Enregistrer sur Shared Drive lorsque le support a besoin que les preuves survivent à la fenêtre normale de rétention des journaux d’exécution. Le compte a besoin d’un lecteur accessible en écriture pour cela. Gardez les preuves de longue durée nettoyées et approuvées par le client. Consultez Archibot d’espace de travail et Shared Drive pour voir comment fonctionne l’accès au lecteur à portée limitée.

Les relecteurs devraient pouvoir répondre à trois questions depuis Console avant de fusionner :

• Qu’est-ce qui a changé, y compris les diffs empilés ?
• Quelles vérifications de revue, de QA et de destination ont été exécutées ?
• Où se trouvent les preuves nettoyées si l’exécution nécessite une revue de support ultérieurement ?

Ne partagez pas :

• Clés d’API, jetons de fournisseur, secrets de webhook, cookies ou liens d’invitation.
• Kubernetes Secrets, variables d’environnement de pod, kubeconfigs ou jetons Coder.
• URL de base de données brutes, contenus de sauvegarde bruts ou fichiers de licence.
• Transcriptions privées ou vidages de données client.

Blocages courants

Transfert au support

Pour le support, incluez :

• Le compte client et le nom de l’environnement.
• L’ID de l’événement de fusion ou l’ID d’exécution CI.
• La branche source, la branche cible et le numéro de demande de fusion du fournisseur lorsqu’il est visible.
• L’étape qui est bloquée.
• L’erreur Console nettoyée ou le résumé du journal.

N’incluez pas d’identifiants bruts, de journaux complets contenant des secrets, de données de base de données privées ou de liens à usage unique. Consultez Transfert au support pour la liste complète de vérification des preuves.