Planification de la mise à niveau

AEM Aperçu du projet

AEM est souvent utilisé dans des déploiements à fort impact qui peuvent servir des millions d’utilisateurs. En règle générale, certaines applications personnalisées sont déployées sur les instances, ce qui ajoute à la complexité. Tout effort de mise à niveau d’un tel déploiement doit être géré méthodiquement.

Ce guide vous aide à définir des objectifs, des phases et des livrables clairs lors de la planification de votre mise à niveau. Il se concentre sur l’exécution globale du projet et sur les directives. Bien qu’il donne un aperçu des étapes de mise à niveau, il se réfère aux ressources techniques disponibles le cas échéant. Il doit être utilisé avec les ressources techniques disponibles auxquelles il est fait référence dans le document.

Le processus de mise à niveau d’AEM nécessite une gestion attentive des phases de planification, d’analyse et d’exécution, avec des éléments livrables clés définis pour chaque phase.

Il est possible de mettre à niveau directement AEM versions 6.0 et jusqu'à 6.5. Les clients utilisant la version 5.6.x ou antérieure doivent d’abord effectuer la mise à niveau vers la version 6.0 ou ultérieure, avec la version 6.0 (SP3) recommandée. En outre, le nouveau format Oak Segment Tar est désormais utilisé pour le magasin de noeuds de segments depuis la version 6.3, et la migration du référentiel vers ce nouveau format est obligatoire, même pour les versions 6.0, 6.1 et 6.2.

Portée et exigences de la mise à niveau

Vous trouverez ci-dessous une liste des zones affectées par un projet de mise à niveau AEM type :

Il est important de vous assurer que vous exécutez un système d’exploitation pris en charge, le runtime Java™, httpd et la version de Dispatcher. Pour plus d’informations, voir la page Exigences techniques d’AEM 6.5. La mise à niveau de ces composants doit être prise en compte dans le plan de votre projet et doit avoir lieu avant la mise à niveau d’AEM.

Phases du projet

La planification et l’exécution d’une mise à niveau d’AEM nécessitent beaucoup de travail. Afin de clarifier les différents efforts déployés dans ce processus, l'Adobe a divisé les exercices de planification et d'exécution en phases distinctes. Dans les sections ci-dessous, chaque phase génère un livrable souvent utilisé par une phase ultérieure du projet.

Planification de la formation des auteurs

Dans toute nouvelle version, d’éventuelles modifications de l’interface utilisateur et des workflows utilisateur peuvent être introduites. En outre, les nouvelles versions introduisent de nouvelles fonctionnalités qui peuvent être utiles à l’entreprise. Adobe recommande de passer en revue les modifications fonctionnelles qui ont été introduites et d’organiser un plan pour former vos utilisateurs à leur utilisation efficace.

Les nouvelles fonctionnalités d’AEM 6.5 sont présentées dans la section AEM d’adobe.com. Veillez à noter toute modification apportée aux interfaces utilisateur ou aux fonctionnalités de produit couramment utilisées dans votre entreprise. Au fur et à mesure que vous examinez les nouvelles fonctionnalités, prenez également note de celles qui peuvent être utiles à votre organisation. Après avoir étudié les changements d’AEM 6.5, élaborez un plan de formation pour vos auteurs. Cela peut impliquer l’utilisation de ressources disponibles gratuitement, telles que des vidéos de présentation de l’aide ou une formation officielle proposée par Adobe des services de formation numérique.

Création d’un plan de test

La mise en oeuvre de l’AEM par chaque client est unique et a été personnalisée pour répondre aux besoins de son entreprise. Par conséquent, il est important de déterminer toutes les personnalisations qui ont été apportées au système afin qu’elles puissent être incluses dans un plan de test. Ce plan de test alimente le processus d’assurance qualité que Adobe exécute sur l’instance mise à niveau.

L’environnement de production exact doit être dupliqué et le test doit y être effectué après la mise à niveau pour s’assurer que toutes les applications et le code personnalisé s’exécutent toujours selon vos besoins. Réglez toutes vos personnalisations et exécutez les tests de performance, de chargement et de sécurité. Lors de l’organisation de votre plan de test, veillez à couvrir toutes les personnalisations apportées au système en plus des interfaces utilisateur et des workflows prêts à l’emploi utilisés dans vos opérations quotidiennes. Il peut s’agir de services et servlets OSGI personnalisés, d’intégrations à Adobe Experience Cloud, d’intégrations à des tiers par le biais de connecteurs d’AEM, d’intégrations tierces personnalisées, de composants et de modèles personnalisés, de superpositions d’interface utilisateur personnalisées dans AEM et de workflows personnalisés. Pour les clients effectuant la migration à partir d’une version antérieure à AEM 6, toutes les requêtes personnalisées doivent être analysées, car elles peuvent nécessiter une indexation. Pour les clients qui utilisent déjà une version 6.x d’AEM, ces requêtes doivent toujours être testées afin de s’assurer que leurs index continuent à fonctionner efficacement après la mise à niveau.

Détermination des changements d’architecture et d’infrastructure nécessaires

Lors de la mise à niveau, il est possible que vous deviez également mettre à niveau d’autres composants de votre pile technique, tels que le système d’exploitation ou la JVM. En outre, il est possible qu’en raison de modifications de la composition du référentiel, un matériel supplémentaire soit nécessaire. Cela concerne uniquement les clients effectuant la migration à partir d’instances antérieures à la version 6.x, mais il est important de tenir compte de cette situation. Enfin, il se peut que des modifications soient nécessaires à vos pratiques opérationnelles, notamment les processus de surveillance, de maintenance, de sauvegarde et de reprise sur sinistre.

Passez en revue les exigences techniques pour AEM 6.5 et vérifiez si votre logiciel et votre matériel actuels sont suffisants. Pour connaître les modifications possibles de vos processus opérationnels, consultez les documents suivants :

Surveillance et maintenance :

Tableau de bord des opérations

Bonnes pratiques en matière de surveillance des ressources

Contrôle des ressources de serveur à l’aide de la console JMX

Nettoyage de révision

Sauvegarde/restauration et reprise sur sinistre :

Sauvegarde et restauration

Performance et évolutivité

Exécution d’AEM avec TarMK Cold Standby

Observations relatives à la restructuration du contenu

AEM s’accompagne de modifications au niveau de la structure du référentiel pour rendre les mises à niveau encore plus transparentes. Cela consiste notamment à déplacer le contenu du dossier /etc vers les dossiers /libs, /apps et /content, selon que le contenu appartient à Adobe ou à un client, ce qui limite les risques d’écrasement du contenu au cours des publications. La restructuration du référentiel a été effectuée de manière à ne pas nécessiter de modifications du code au moment de la mise à niveau vers la version 6.5, bien qu’il soit recommandé de consulter les détails à l’adresse Restructuration des référentiels dans AEM lors de la planification d’une mise à niveau.

Évaluation de la complexité de la mise à niveau

En raison de la grande variété de la quantité et de la nature des personnalisations que les clients d’Adobe appliquent à leurs environnements AEM, il est important de passer du temps à déterminer le niveau d’effort global attendu dans votre mise à niveau.

Vous pouvez suivre deux approches pour évaluer la complexité de la mise à niveau. Une phase préliminaire peut utiliser le nouvel outil de détection des motifs disponible pour être exécuté sur vos instances AEM 6.1, 6.2 et 6.3. Le détecteur de motifs est le moyen le plus simple d’évaluer la complexité globale de la mise à niveau à prévoir à l’aide des modèles signalés. Le rapport de l’outil de détection des motifs comprend des motifs permettant d’identifier les API indisponibles utilisées par le code base personnalisé (cela a été effectué à l’aide des vérifications de compatibilité avant la mise à niveau dans la version 6.3).

Une fois l’évaluation initiale terminée, une procédure plus approfondie consiste à effectuer une mise à niveau sur une instance de test et à réaliser quelques tests de vérification. Adobe en propose également quelques. La liste des Fonctionnalités obsolètes et supprimées doit être examiné non seulement pour la version vers laquelle vous effectuez la mise à niveau, mais également pour toutes les versions entre vos versions source et cible. Par exemple, si vous passez d’AEM 6.2 à 6.5, il est important de passer en revue les fonctionnalités supprimées et obsolètes d’AEM 6.3 en plus de celles d’AEM 6.5.

L’outil de détection des motifs introduit récemment devrait vous donner une idée assez précise de ce à quoi vous devez vous attendre la plupart du temps au cours d’une mise à niveau. Cependant, pour les personnalisations et déploiements plus complexes comportant des modifications incompatibles, vous pouvez mettre à niveau une instance vers AEM 6.5 conformément aux instructions de la section Exécution d’une mise à niveau statique. Une fois l’opération terminée, effectuez un test de vérification de haut niveau dans cet environnement. L’objectif de cet exercice n’est pas d’épuiser l’inventaire exhaustif des scénarios de tests et de développer un inventaire formel des éléments défectueux, mais de donner une estimation approximative de la quantité de travail requise pour mettre à niveau le code pour assurer la compatibilité avec la version 6.5. Lorsqu’elle est combinée avec la variable Détection de motifs et les changements architecturaux qui ont été déterminés dans la section précédente, une estimation approximative peut être fournie à l’équipe de gestion de projet pour la planification de l’upgrade.

Création du runbook de mise à niveau et de restauration

Bien qu’Adobe ait documenté le processus de mise à niveau d’une instance d’AEM, la disposition réseau, l’architecture de déploiement et les personnalisations de chaque client nécessitent d’affiner et de personnaliser cette approche. C’est pourquoi Adobe vous encourage à consulter l’ensemble de la documentation fournie et à l’utiliser pour informer un runbook spécifique au projet qui décrit les procédures de mise à niveau et de restauration spécifiques que vous allez suivre dans votre environnement. Si vous effectuez une mise à niveau à partir de CRX2, veillez à évaluer la durée de migration du contenu lors du passage de CRX2 à Oak. Pour les référentiels volumineux, cela peut être important.

Adobe a fourni des procédures de mise à niveau et de restauration dans Procédure de mise à niveau et instructions détaillées pour appliquer la mise à niveau dans Exécution d’une Mise à niveau statique. Ces instructions doivent être examinées et prises en compte avec l’architecture de votre système, les personnalisations et la tolérance aux temps d’arrêt afin de déterminer les procédures de basculement et de restauration appropriées que vous exécuterez lors de la mise à niveau. Toute modification de l’architecture ou des tailles de serveur doit être incluse lors de la rédaction de votre runbook personnalisé. Il est important de noter que ceci doit être traité comme une première version préliminaire. Pendant que votre équipe termine le contrôle qualité et les cycles de développement, et déploie la mise à niveau sur l’environnement d’évaluation, il est problable que vous ayez besoin de prendre des mesures supplémentaires. Idéalement, ce document doit contenir suffisamment d’informations pour que, s’il était transmis à un membre de votre personnel d’exploitation, celui-ci puisse effectuer entièrement l’upgrade à partir des informations contenues dans le document.

Développement d’un plan de projet

Les résultats des exercices précédents peuvent être utilisés pour créer un plan de projet qui couvre les calendriers prévus pour vos tests ou efforts de développement, la formation et l’exécution réelle de la mise à niveau.

Un plan de projet complet doit comprendre les éléments suivants :

• La finalisation du développement et des plans de tests
• La mise à niveau du développement et des environnements de contrôle qualité
• La mise à niveau de la base de code personnalisé pour AEM 6.5
• Un test de contrôle qualité et une période de mise au point
• Une mise à niveau de l’environnement d’évaluation
• Test d’intégration, de performance et de chargement
• La certification de l’environnement
• Go live

Exécution du développement et de l’assurance qualité

Adobe a fourni des procédures pour Mise à niveau du code et des personnalisations pour être compatible avec AEM 6.5. Au fur et à mesure que ce processus itératif est exécuté, des modifications doivent être apportées au runbook selon les besoins. Voir aussi Compatibilité descendante dans AEM 6.5 sur les informations sur la façon dont vos personnalisations peuvent rester rétrocompatibles, généralement sans nécessiter de développement immédiatement après la mise à niveau.

Le processus de développement et de test est généralement itératif. En raison des personnalisations, les modifications apportées pendant la mise à niveau peuvent rendre toute une section du produit inutilisable. Une fois que les développeurs ont traité la cause du problème et que l’équipe de test a accès à ces fonctionnalités, il est possible de découvrir d’autres problèmes. À mesure que des problèmes qui nécessitent des ajustements au processus de mise à niveau sont découverts, veillez à les ajouter à votre runbook de mise à niveau personnalisé. Après plusieurs itérations de test et de correction, la base de code doit être entièrement validée et prête à être déployée dans l’environnement d’évaluation.

Test final

Adobe recommande un dernier cycle de tests une fois que le code base a été certifié par l’équipe d’assurance qualité de votre entreprise. Ce cycle de tests implique la validation de votre runbook dans un environnement d’évaluation suivi de séries de tests d’acceptation par l’utilisateur, de performances et de sécurité.

Cette étape est essentielle, car c’est la seule fois où vous pouvez valider les étapes du runbook par rapport à un environnement de type production. Une fois l’environnement mis à niveau, il est important de laisser aux utilisateurs finaux le temps de se connecter et de parcourir les activités qu’ils effectuent lors de l’utilisation du système dans leurs activités quotidiennes. Il n’est pas rare que les utilisateurs utilisent une partie du système qui n’a pas été précédemment prise en compte. Trouver et corriger les problèmes dans ces zones avant la mise en service peut aider à éviter des pannes de production coûteuses. Comme une nouvelle version d’AEM contient des modifications importantes de la plateforme sous-jacente, il est également important d’effectuer des tests de performance, de chargement et de sécurité sur le système comme si vous l’aviez lancé pour la première fois.

Mise à niveau

Une fois que l’approbation finale a été reçue de toutes les parties prenantes, il est temps de l’exécuter sur les procédures définies du runbook. Adobe a fourni des étapes pour la mise à niveau et la restauration Procédure de mise à niveau et étapes d’installation dans Exécution d’une Mise à niveau statique comme point de référence.

Adobe a fourni quelques étapes dans les instructions de mise à niveau pour la validation de l’environnement. Il s’agit notamment de vérifications de base, comme l’analyse des journaux de mise à niveau et la vérification que tous les lots OSGi ont correctement démarré. Adobe recommande toutefois de procéder également à la validation avec vos propres cas de test en fonction de vos processus d’entreprise. Adobe recommande également de vérifier la planification du nettoyage des révisions en ligne AEM et les routines associées afin de s’assurer qu’elles se produisent pendant une période calme pour votre entreprise. Ces routines sont essentielles à la performance à long terme de l'AEM.