Pipelines et déploiements Version 24.1.2 du workflow

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 progressent 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. Extrait 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 notifier au demandeur que la demande a été créée.
   5. Publie l’application dans le Référentiel d'applicationsfichier .
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 de pipeline .
      1. Si l’environnement suivant n’existe pas, le système envoie un e-mail à partir de l’instance de contrôleur pour notifier le demandeur que la demande a été fermée et que l’application a été publiée dans 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 de contrôleur pour informer le demandeur que sa 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 que l’environnement cible est en 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 la suite d’analyse d’instance de 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 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 du contrôleur.
      4. Écrit les résultats de Instance Scan et des tests ATF dans la table Résultat de l’environnement de déploiement et le flux d’activité sur la demande de déploiement.
      5. Ramène le workflow à l’étape 3, où il recherche des 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 lors de 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 définie ou non sur l’état Implémenter .
         1. Si l’état de la demande de changement n’est pas Implémenter et que l’état n’est ni Évaluer ni Autoriser, le système envoie un e-mail à partir de l’instance du contrôleur pour notifier le demandeur que sa demande n’a pas été approuvée et qu’elle a été fermée. Le workflow est terminé.
         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 dans 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 ni maintenant ni dans le passé, le système attend que ces deux conditions soient vraies
      5. Si l’état de la demande de changement est défini sur 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 de contrôleur pour notifier le demandeur que sa demande n’a pas été approuvée et a été fermée. Le workflow est terminé.
      6. Si l’état de la demande de changement est défini sur 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 planifiée dans la demande de changement. Le système ferme la tâche de changement, puis ferme la demande de déploiement. Le workflow est terminé.
   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.