Pipelines et déploiements Version de workflow 24.1.2

Lorsque vous gérez les demandes de déploiement d’applications dans App Engine Management Center (AEMC), utilisez ce workflow pour comprendre comment les déploiements d’applications se déplacent dans vos pipelines dans la version 24.1.2, publiée en novembre 2023.

Figure 1. Workflow Pipelines et déploiements

Dans ce workflow :

1. Le demandeur sélectionne Soumettre dans App Engine Studio, Creator Studioou , ce ServiceNow Studioqui déclenche le flux principal.
2. Le système effectue les tâches suivantes en arrière-plan :
   1. Valide la charge utile.
   2. Récupère le manifeste de l’application à partir de l’enregistrement de sys_app sur l’instance source.
   3. Crée une demande de déploiement sur l’instance du contrôleur.
   4. Envoie un e-mail à partir de l’instance du contrôleur pour informer le demandeur que la demande a été créée.
   5. Publie l’application dans le Référentiel d'applications.
3. Le système effectue différentes actions selon qu’il y a des erreurs ou non lors de la publication.
   1. Si des erreurs se sont produites dans la publication de l’application et que la gravité de l’erreur est Erreur, le système crée et attend l’approbation de l’enregistrement mis à jour.
   2. S’il n’y a pas d’erreur, ou s’il y a des erreurs, mais que la gravité de l’erreur n’est pas Erreur, le système recherche l’environnement suivant sur l’enregistrement du pipeline.
      1. Si l’environnement suivant n’existe pas, le système envoie un e-mail à partir de l’instance du contrôleur pour informer le demandeur que la demande a été fermée et que l’application a été publiée sur l’instance cible. Cette action met fin au workflow.
      2. Si l’environnement suivant existe, le système met à jour le champ Environnement cible de la demande de déploiement vers l’environnement suivant. Ensuite, le système crée et attend l’approbation de l’enregistrement mis à jour.
4. Le système effectue différentes actions selon que le nouvel enregistrement a été approuvé ou non.
   1. Si l’enregistrement n’est pas approuvé, le système envoie un e-mail à partir de l’instance du contrôleur pour informer le demandeur que la demande n’a pas été approuvée et que la demande a été fermée. Cette action met fin au workflow.
   2. Si l’enregistrement est approuvé et si l’environnement cible est en cours de test, le système effectue les actions suivantes :
      1. Déploie l’application dans l’environnement de tests, si l’application n’y est pas disponible.
      2. Exécute l’analyse d’instance des définitions d’application incluses dans le périmètre et toutes les autres suites de la table Suites d’analyse [[scan_suites]] de l’instance de test.
         Remarque :

         La table Suites d’analyse doit être renseignée sur l’instance du contrôleur.
      3. Exécute la suite de tests de déploiement d’application, la suite Framework de tests automatisés (ATF) et toutes les suites de la table Suites d’analyse [scan_suites] de l’instance de test.
      4. Écrit les résultats des analyses d’instance et des tests ATF dans la table des résultats de l’environnement de déploiement et dans le flux d’activité de la demande de déploiement.
      5. Ramène le workflow à l’étape 3, où il vérifie les erreurs.
   3. Si l’enregistrement est approuvé et que l’environnement cible est Production, l’application commence le processus de déploiement planifié avec l’intégration de Gestion des changements.
      1. L’administrateur App Engine sélectionne Approuver et créer une demande de changement. Une demande de changement est créée en fonction du modèle choisi pendant la configuration guidée.
      2. Le système effectue différentes actions selon que l’application est enregistrée ou non en tant qu’élément de configuration (CI).
         1. Si l’application n’est pas enregistrée en tant que CI, le système enregistre l’application en tant que CI, puis ajoute le CI affecté à la demande de changement.
         2. Si l’application est enregistrée en tant que CI, le système ajoute le CI affecté à la demande de changement.
      3. Le système effectue différentes actions selon que la demande de changement est à l’état Implémenter ou non.
         1. Si l’état de la demande de changement n’est pas Implémenter et que l’état n’est pas Évaluation ou Autorisation, le système envoie un e-mail à partir de l’instance du contrôleur pour informer le demandeur que sa demande n’a pas été approuvée et a été fermée. Ceci met fin au workflow.
         2. Si l’état de la demande de changement n’est pas Implémenter et que l’état est Évaluation ou Autoriser, le système attend que l’état soit Implémentation.
         3. Si la demande de changement est à l’état Implémenter , le système crée une tâche de changement pour planifier le déploiement de l’application.
      4. Si l’état de la demande de changement est Implémenter et que la date de début prévue n’est pas Maintenant ou dans le passé, le système attend que ces deux conditions soient vraies
      5. Si l’état de la demande de changement est Implémenter et que la date de début prévue est Maintenant ou dans le passé, mais que la demande est rejetée ou annulée, le système envoie un e-mail à partir de l’instance du contrôleur pour informer le demandeur que sa demande n’a pas été approuvée et a été fermée. Ceci met fin au workflow.
      6. Si l’état de la demande de changement est Implémenter et que la date de début planifiée est Maintenant ou dans le passé, le système planifie le déploiement de l’application en production en fonction de la date de début planifiée dans la demande de changement. Le système ferme la tâche de changement, puis ferme la demande de déploiement. Ceci met fin au workflow.
   4. Si l’enregistrement est approuvé et que l’environnement cible n’est pas Test ou Production, le système déploie l’application dans l’environnement cible, si elle n’y est pas disponible.

      Le workflow recommence lorsqu’un demandeur sélectionne à nouveau Soumettre dans App Engine Studio, Creator Studioou ServiceNow Studio.