Show Menu
SUJETS×

Déploiement de votre code

Déploiement du code avec Cloud Manager

Une fois que vous avez configuré votre pipeline de production (référentiel, environnement et environnement de test), vous êtes prêt à déployer votre code.
  1. Cliquez sur Déployer dans Cloud Manager pour lancer le processus de déploiement.
  2. L’écran Exécution du pipeline s’affiche.
    Cliquez sur Générer pour lancer le processus.
  3. Le processus de création complet déploie le code.
    Les étapes suivantes sont impliquées dans le processus de création :
    1. Déploiement dans l’environnement intermédiaire
    2. Test dans l’environnement intermédiaire
    3. Déploiement dans l’environnement de production
    En outre, vous pouvez examiner les étapes de divers processus de déploiement en affichant les journaux ou en examinant les résultats pour les critères de test.
    Le déploiement en environnement intermédiaire comprend les étapes suivantes :
    • Validation : cette étape permet de s’assurer que le pipeline est configuré pour utiliser les ressources actuellement disponibles ; par exemple, la branche configurée existe, les environnements sont disponibles, etc.
    • Test de création et d’unité : cette étape exécute un processus de création en conteneur. Pour plus d’informations sur l’environnement de création, voir Détails de l’Environnement de création.
    • Analyse du code : cette étape évalue la qualité du code de votre application. Voir Test de la qualité du code pour plus d’informations sur le processus de test.
    • Compiler des images : cette étape comprend un fichier journal du processus utilisé pour compiler des images. Ce processus est responsable de la transformation du contenu et des modules du Dispatcher générés par l’étape de compilation en images Docker et en configuration Kubernetes.
    • Déploiement dans l’environnement d’évaluation.
      Le test dans l’environnement intermédiaire comprend les étapes suivantes :
    • Test fonctionnel du produit : Les exécutions du pipeline Cloud Manager prendront en charge l’exécution de tests exécutés par rapport à l’environnement d’affichage. Refer to Product Functional Testing for more details.
    • Tests fonctionnels personnalisés : cette étape du pipeline est toujours présente et ne peut pas être ignorée. Cependant, si aucun fichier JAR de test n’est généré par la compilation, le test réussit par défaut.\
      Refer to Custom Functional Testing for more details.
    • Audit d’expérience : Cette étape du pipeline est toujours présente et ne peut pas être ignorée. Lorsqu’un pipeline de production est exécuté, une étape de contrôle d’expérience est incluse après des tests fonctionnels personnalisés qui exécuteront les contrôles. Les pages configurées seront envoyées au service et évaluées. Les résultats sont informatifs et permettent à l’utilisateur de voir les scores et le changement entre les scores actuel et précédent. Cette connaissance est utile pour déterminer si une régression est introduite avec le déploiement actuel. Pour plus d’informations, voir Comprendre les résultats de l’audit d’expérience.

Processus de déploiement

La section suivante décrit le déploiement des packages AEM et dispatcher dans les phases intermédiaires et de production.
Cloud Manager télécharge tous les fichiers target/*.zip générés par le processus de création vers un emplacement de stockage. Ces artefacts sont récupérés à partir de cet emplacement pendant les phases de déploiement du pipeline.
Lorsque Cloud Manager se déploie sur des topologies autres que de production, l’objectif est de réaliser le déploiement aussi rapidement que possible ; les artefacts sont donc déployés simultanément sur tous les nœuds, comme suit :
  1. Cloud Manager détermine si chaque artefact est un package AEM ou dispatcher.
  2. Cloud Manager supprime tous les dispatchers de l’équilibreur de charge pour isoler l’environnement pendant le déploiement.
    Sauf configuration contraire, vous pouvez ignorer les modifications de l’équilibreur de charge dans les déploiements de développement et en environnement intermédiaire, c’est-à-dire détacher et attacher des étapes dans les deux pipelines hors production, pour les environnements de développement et le pipeline de production, pour les environnements intermédiaires.
    Cette fonctionnalité devrait principalement être utilisée par les clients 1-1-1.
  3. Chaque artefact AEM est déployé sur chacune des instances AEM par le biais des API de Package Manager, avec des dépendances de packages qui déterminent l’ordre de déploiement.
    Pour en savoir plus sur l’utilisation de packages pour installer de nouvelles fonctionnalités, transférer du contenu entre des instances et sauvegarder le contenu du référentiel, reportez-vous à la section Utilisation de packages.
    Tous les artefacts AEM sont déployés à la fois sur author et publishers. Les modes d’exécution doivent être exploités lorsque des configurations spécifiques aux noeuds sont requises. Pour en savoir plus sur la façon dont les modes d'exécution vous permettent d'ajuster votre instance AEM pour un objectif spécifique, reportez-vous à la section Modes d'exécution.
  4. L’artefact dispatcher est déployé sur chaque dispatcher comme suit :
    1. Les configurations actuelles sont sauvegardées et copiées vers un emplacement temporaire.
    2. Toutes les configurations sont supprimées, à l’exception des fichiers non modifiables. Pour plus d’informations, consultez la section Gestion des configurations du Dispatcher. Cela permet de vider les répertoires pour qu’aucun fichier orphelin ne soit abandonné.
    3. L’artefact est extrait dans le répertoire httpd . Les fichiers non modifiables ne sont pas remplacés. Toute modification apportée aux fichiers non modifiables dans votre référentiel git sera ignorée au moment du déploiement. Ces fichiers sont essentiels à la structure du dispatcher AMS et ne peuvent pas être modifiés.
    4. Apache effectue un test de configuration. Si aucune erreur n’est trouvée, le service est rechargé. Si une erreur se produit, les configurations sont restaurées à partir de la sauvegarde, le service est rechargé et l’erreur est renvoyée à Cloud Manager.
    5. Chaque chemin spécifié dans la configuration de pipeline est invalidé ou purgé du cache du dispatcher.
    Cloud Manager exige que l’artefact du dispatcher contienne le jeu de fichiers complet. Tous les fichiers de configuration du dispatcher doivent être présents dans le référentiel git. Les fichiers ou dossiers manquants entraînent l’échec du déploiement.
  5. Après le déploiement réussi de tous les packages AEM et de dispatcher sur tous les nœuds, les dispatchers sont ajoutés à l’équilibreur de charge et le déploiement est terminé.
    Vous pouvez ignorer les modifications de l’équilibreur de charge dans les déploiements de développement et d’évaluation, c’est-à-dire, détacher et attacher des étapes dans les deux pipelines hors production, pour les environnements de développement et le pipeline de production, pour les environnements d’évaluation.

Phase de déploiement en production

Le processus de déploiement des topologies de production diffère légèrement afin de minimiser l’impact sur les visiteurs d’AEM Site.
Les déploiements en production suivent généralement les mêmes étapes que ci-dessus, mais par roulements :
  1. Déploiement des packages AEM sur author.
  2. Détachement de dispatcher1 de l’équilibreur de charge.
  3. Déploiement des packages AEM sur publish1 et le package dispatcher sur dispatcher1. Purge du cache du dispatcher.
  4. Replacement du dispatcher1 dans l’équilibreur de charge.
  5. Lorsque dispatcher1 fonctionne à nouveau, détachement de dispatcher2 de l’équilibreur de charge.
  6. Déploiement des packages AEM sur publish2 et le package dispatcher sur dispatcher2. Purge du cache du dispatcher.
  7. Replacement du dispatcher2 dans l’équilibreur de charge. Ce processus se poursuit jusqu’à ce que le déploiement ait atteint tous les publishers et dispatchers dans la topologie.