Pipelines et déploiements Version 24.1.2 du workflow

Lorsque vous gérez les demandes de déploiement d’applications dans Centre de gestion du moteur de développement d'application (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 Envoyer dans Studio du moteur de développement d'application, 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 d’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 depuis 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 pendant la publication.
   1. Si des erreurs se sont produites dans la publication de l’application, dont la gravité est Erreur, le système crée l’enregistrement mis à jour et attend l’approbation.
   2. S’il n’y a pas d’erreurs, ou s’il y en a, 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 informer 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 des actions différentes 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 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 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 la suite d’analyse d’instance 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 du contrôleur.
      3. Exécute la suite de tests de déploiement d’application , la suite ATF (Automated Test Framework) et toutes les suites de la table Suites d’analyse [scan_suites] de l’instance du contrôleur.
      4. Écrit les résultats des tests Instance Scan et 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. renvoie 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 Change Management.
      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 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 inscrit 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 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 Évaluer ou Autoriser, le système attend que l’état soit Implémenter.
         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 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 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 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. 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.