Pipelines et déploiements Version du 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, ce qui 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 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 la publication de l’application comporte des erreurs 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 incluse dans le périmètre et toute autre suite 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 Infrastructure de tests automatisés (ATF) et toutes les suites de la table Suites d’analyse [scan_suites] sur l’instance de test.
      4. Écrit les résultats de Instance Scan et des tests ATF dans la table 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 du moteur de développement d’application 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 inscrite 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 l’enregistre 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 Évaluer ou Autoriser, 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 Évaluer 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é ou Annulé, 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 prévue 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 prévue 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 ni Test ni 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.