Pour en savoir plus sur le déploiement du code pour Cloud Manager dans AEM as a Cloud Service, consultez ce lien.
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.
Cliquez sur Déployer dans Cloud Manager pour lancer le processus de déploiement.
L’écran Exécution du pipeline s’affiche.
Cliquez sur Compilation pour lancer le processus.
Le processus de création complet déploie le code.
Les étapes suivantes sont impliquées dans le processus de création :
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 dans l’environnement intermédiaire comprend les étapes suivantes :
Le test dans l’environnement intermédiaire comprend les étapes suivantes :
Le déploiement en environnement de production comprend les étapes suivantes :
La planification du déploiement en production est activée lors de la configuration du pipeline.
Grâce à cette option, vous pouvez planifier le déploiement en production ou cliquer sur Maintenant pour exécuter immédiatement le déploiement en production.
La date et l’heure planifiées sont indiquées dans le fuseau horaire de l’utilisateur.
Cliquez sur Confirmer pour vérifier vos paramètres.
Une fois que vous avez confirmé la planification du déploiement, votre déploiement du code se termine.
L’écran suivant s’affiche lorsque l’option Maintenant est sélectionnée à l’étape précédente.
Les étapes suivantes expirent s’ils sont en attente de commentaires de l’utilisateur :
Étape | Délai dépassé |
---|---|
Test de qualité du code | 14 jours |
Test de sécurité | 14 jours |
Test de performance | 14 jours |
Application à approuver | 14 jours |
Planning du déploiement en production | 14 jours |
Assistance de l’ingénieur du service client | 14 jours |
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 :
Cloud Manager détermine si chaque artefact est un package AEM ou dispatcher.
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.
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 l’instance de création et les instances de publication. Les modes d’exécution doivent être utilisés lorsque des configurations spécifiques à un nœud sont requises. Pour en savoir plus sur la façon dont les modes d’exécution vous permettent d’ajuster votre instance AEM à des fins spécifiques, consultez Modes d’exécution.
L’artefact dispatcher est déployé sur chaque dispatcher comme suit :
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.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.
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, ainsi que dans le pipeline de production, pour les environnements d’évaluation.
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 :
Dans les situations critiques, les clients d’Adobe Managed Services peuvent devoir déployer les modifications de code dans leurs environnements intermédiaire et de production sans attendre l’exécution d’un cycle de test complet de Cloud Manager.
Pour résoudre ces problèmes, le pipeline de production de Cloud Manager peut être exécuté en mode d’urgence. Lorsque ce mode est utilisé, les étapes de test de sécurité et de performance ne sont pas exécutées ; toutes les autres étapes, y compris les étape de validation configurées, sont exécutées comme dans le mode normal d’exécution du pipeline.
La fonctionnalité Mode d’exécution d’urgence du pipeline est activée au niveau du programme par les ingénieurs de réussite client.
Lorsque vous démarrez l’exécution d’un pipeline de production, si cette fonctionnalité a été activée, vous pouvez le faire en mode normal ou d’urgence à partir de la boîte de dialogue, comme illustré ci-dessous.
En outre, en affichant la page des détails d’exécution du pipeline pour une exécution en mode d’urgence, le chemin de navigation en haut de l’écran affiche un indicateur indiquant que le mode d’urgence a été utilisé pour cette exécution en particulier.
Vous pouvez également créer une exécution de pipeline dans ce mode d’urgence à l’aide de l’API Cloud Manager ou de l’interface de ligne de commande. Pour démarrer une exécution en mode d’urgence, envoyez une requête PUT au point d’entrée d’exécution du pipeline avec le paramètre de requête ?pipelineExecutionMode=EMERGENCY
ou lors de l’utilisation de l’interface de ligne de commande :
$ aio cloudmanager:pipeline:create-execution PIPELINE_ID --emergency
L’utilisation de l’indicateur --emergency
peut nécessiter une mise à jour vers la dernière version de l’aio-cli-plugin-cloudmanager
.
La réexécution de l’étape de déploiement en production est prise en charge pour les exécutions où l’étape de déploiement en production est terminée. Le type d’achèvement n’est pas important : le déploiement peut être réussi (uniquement pour les programmes AMS), annulé ou non réussi. Cela dit, le cas d’utilisation principal doit être celui où l’étape de déploiement en production a échoué pour des raisons transitoires. La réexécution crée une nouvelle exécution à l’aide du même pipeline. Cette nouvelle exécution se compose de trois étapes :
L’étape de création peut être libellée de façon légèrement différente dans l’interface utilisateur afin de refléter le fait qu’elle copie (et ne récrée pas) des artefacts.
Restrictions :
Pour déterminer si une exécution est une exécution de ré-exécution, le champ déclencheur peut être examiné. Sa valeur sera RE_EXECUTE.
Pour déclencher une réexécution, une requête PUT doit être envoyée au lien HAL http://ns.adobe.com/adobecloud/rel/pipeline/reExecute
à l’état d’étape de déploiement en production. Si ce lien est présent, l’exécution peut être redémarrée à partir de cette étape. En cas d’absence, l’exécution ne peut pas être redémarrée à partir de cette étape. Dans la version initiale, ce lien sera uniquement présent lors de l’étape de déploiement en production, mais les prochaines versions peuvent prendre en charge le démarrage du pipeline à partir d’autres étapes. Exemple :
{
"_links": {
"http://ns.adobe.com/adobecloud/rel/pipeline/logs": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/logs",
"templated": false
},
"http://ns.adobe.com/adobecloud/rel/pipeline/reExecute": {
"href": "/api/program/4/pipeline/1/execution?stepId=2983530",
"templated": false
},
"http://ns.adobe.com/adobecloud/rel/pipeline/metrics": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530/metrics",
"templated": false
},
"self": {
"href": "/api/program/4/pipeline/1/execution/953671/phase/1575676/step/2983530",
"templated": false
}
},
"id": "6187842",
"stepId": "2983530",
"phaseId": "1575676",
"action": "deploy",
"environment": "weretail-global-b75-prod",
"environmentType": "prod",
"environmentId": "59254",
"startedAt": "2022-01-20T14:47:41.247+0000",
"finishedAt": "2022-01-20T15:06:19.885+0000",
"updatedAt": "2022-01-20T15:06:20.803+0000",
"details": {
},
"status": "FINISHED"
La syntaxe de la valeur href du lien HAL ci-dessus n’est pas destinée à être utilisée comme point de référence. La valeur réelle doit toujours être lue à partir du lien HAL et non générée.
L’envoi d’une requête PUT vers ce point d’entrée entraîne la génération d’une réponse 201 en cas de réussite, le corps de la réponse étant la représentation de la nouvelle exécution. Cela revient à lancer une exécution régulière via l’API.