Vous consultez actuellement l'aide de la version:

En planifiant une mise à niveau, les parties suivantes de l’implémentation doivent être étudiées et résolues.

Aperçu

  1. Outil de détection des motifs : exécutez l’outil de détection des motifs comme indiqué dans la planification de la mise à niveau et dans la description détaillée sur cette page pour générer un rapport de détection des motifs contenant des informations plus détaillées sur les points à examiner, en plus des API/lots indisponibles dans la version cible d’AEM. Le rapport de détection de motifs doit vous donner une indication quant aux éventuelles incompatibilités de votre code. En l’absence d’incompatibilités, votre déploiement est déjà compatible avec la version 6.4. Vous pouvez toujours choisir de procéder à un nouveau déploiement pour utiliser la fonctionnalité 6.4, mais vous n’en avez pas besoin simplement pour des questions de compatibilité. S’il est fait état d’incompatibilités, vous pouvez soit a) Lancer l’exécution en mode de compatibilité et différer le développement des nouvelles fonctionnalités 6.4 ou de la compatibilité, soit b) Décider de procéder au développement après la mise à niveau, et passer à l’étape 2. Pour plus d’informations, voir Compatibilité descendante dans AEM 6.4.


  2. Développement de la base de code pour la version 6.4 - création d’une branche ou d’un référentiel dédié à la base de code pour la version cible. Utilisez les informations de la compatibilité avant la mise à niveau pour prévoir les zones de code à mettre à jour.
  3. Compilation avec 6.4 Uber jar - Mettre à jour les POM de la base de code pour pointer vers 6.4 Uber jar et compilez le code par rapport à cette opération.
  4. Mise à jour de la personnalisation d’AEM - Toutes les personnalisations ou les extensions dans AEM doivent être mises à jour/validées pour fonctionner dans la version 6.4 et être ajoutées à la base de code 6.4. Comprend des formulaires de recherche, des personnalisations de ressources, tout élément utilisant /mnt/overlay
  5. Déploiement vers l’environnement 6.4 - Une instance AEM 6.4 nette (auteur + publicateur) doit être conservée dans un environnement Dev/QA. La base de code à jour et un échantillon représentatif de contenu (de la production actuelle) doivent être déployés.
  6. Validation du contrôle qualité et correction des bogues - Le contrôle qualité doit valider l’application sur les instances d’auteur et de publication de la version 6.4. Tous les problèmes détectés doivent être corrigés et intégrés dans la base de code 6.4. Répétez le cycle de développement autant de fois que nécessaire jusqu’à ce que tous les problèmes soient corrigés.

Avant d’effectuer une mise à niveau, vous devez disposer d’une base stable de code d’application qui a été complètement testée par rapport à la version cible d’AEM. En fonction des observations effectuées durant le test, il existe des façons d’optimiser le code personnalisé. Cela peut inclure la restructuration du code pour éviter de parcourir le référentiel, l’indexation personnalisée pour optimiser la recherche ou l’utilisation des nœuds non classés dans le JCR, entre autres.

Outre la possibilité de mettre à niveau votre base du code et vos personnalisations afin qu’elles fonctionnent avec la nouvelle version d’AEM, la version 6.4 permet de gérer plus efficacement vos personnalisations à l’aide de la fonctionnalité de compatibilité descendante (ou de rétrocompatibilité) décrite sur cette page.

Comme indiqué ci-dessus et dans le diagramme ci-dessous, le fait d’exécuter l’outil de détection des motifs au cours de la première étape vous aide à évaluer la complexité globale de la mise à niveau et à déterminer si vous souhaitez exécuter le mode de compatibilité ou mettre à jour vos personnalisations afin d’utiliser toutes les nouvelles fonctionnalités d’AEM 6.4. Pour en savoir plus, consultez la page Compatibilité descendante dans AEM 6.4.

Mise à niveau de la base de code

Création d’une branche spécifique pour la version 6.4 du code dans le contrôle de version

Tous les codes et configurations nécessaires à votre implémentation d’AEM doivent être gérés à l’aide d’une forme de contrôle de version. Une branche spécifique dans le contrôle de version doit être créée pour gérer tous les changements requis pour la base de code de la version cible d’AEM. Les tests itératifs de la base de code par rapport à la version cible d’AEM et les corrections de bogues consécutives sont gérés dans cette branche.

Mise à jour de la version AEM Uber Jar

AEM Uber jar inclut toutes les API d’AEM en tant que dépendance unique dans le fichier pom.xml de votre projet Maven. Il est toujours conseillé d’inclure le jar Uber comme dépendance unique au lieu d’incorporer les dépendances individuelles des API d’AEM. En améliorant la base de code, la version du jar Uber doit être modifiée pour indiquer la version cible d’AEM. Si votre projet a été développé sur une version AEM avant l’existence du jar Uber, toutes les dépendances individuelles des API d’AEM doivent être supprimées ou remplacées par une inclusion unique du jar Uber pour la version cible d’AEM. La base de code doit ensuite être recompilés par rapport à la nouvelle version du jar Uber. Toutes les méthodes obsolète d’API doivent être mis à jour pour être compatibles avec la version cible d’AEM.

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.4.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

Élimination graduelle de l’utilisation de l’Administrative Resource Resolver

L’utilisation d’une session d’administration via SlingRepository.loginAdministrative() et ResourceResolverFactory.getAdministrativeResourceResolver() était très courante dans les bases de code avant AEM 6.0. Ces méthodes ont été déconseillées pour des raisons de sécurité, car elles offrent un niveau d’accès trop large. Dans les prochaines versions de Sling, ces méthodes seront supprimées. Il est vivement recommandé de restructurer les codes afin d’utiliser les utilisateurs de service à la place. Plus d’informations sur les utilisateurs de service et la manière d’éliminer les sessions administrative progressivement sont présentées ici.

Requêtes et index Oak

Toute utilisation des requêtes dans la base de code doit être complètement testée dans le cadre de la mise à jour de la base de code. Pour les clients mettant à niveau depuis Jackrabbit 2 (versions AEM plus anciennes que 6.0), cela est particulièrement important, puisque Oak n’indexe pas de contenu automatiquement, et des index personnalisés doivent être créés. Si la mise à jour est effectuée à partir d’une version 6.x d’AEM, les définitions d’index d’Oak ont peut-être été modifiées et sont susceptible d’impacter les requêtes existantes.

Plusieurs outils pour l’analyse et l’inspection de la performance des requête sont disponibles :

IU classique - Création

La création de l’IU classique est toujours disponible dans AEM 6.4, mais elle sera bientôt obsolète. Vous trouverez plus d’informations ici. Si votre application s’exécute dans l’environnement de création de l’interface utilisateur classique, il est recommandé de la mettre à niveau vers AEM 6.4 et de continuer à utiliser l’interface utilisateur classique. La migration vers l’interface utilisateur optimisée pour les écrans tactiles peut ensuite être prévue en tant que projet distinct à effectuer sur plusieurs cycles de développement. Pour utiliser l’interface utilisateur classique dans la version 6.4, plusieurs configurations OSGi sont nécessaires pour être intégrées dans la base de code. Plus d’informations sur la façon de configurer cette fonction, cliquez ici.

Alignement avec la structure de référentiel de la version 6.4

Pour faciliter les mises à niveau et s’assurer que les configurations ne soient pas remplacées au cours de celles-ci, le référentiel est restructuré dans la version 6.4 afin de séparer le contenu de la configuration. 

Plusieurs paramètres doivent donc être déplacés afin de ne plus résider sous /etc, comme c’était le cas auparavant. Pour consulter l’ensemble des problèmes de restructuration de référentiel qui doivent être étudiés et résolus dans la mise à jour d’AEM 6.4, voir Restructuration de référentiel dans AEM 6.4

Personnalisations d’AEM

Toutes les personnalisations apportées à l’environnement de création d’AEM dans la version source d’AEM doivent être identifiées. Une fois identifiées, il est recommandé que chacune des personnalisations soit stockée dans le contrôle de version ou au moins prise en charge dans le cadre d’un module de contenu. Toutes les personnalisations doivent être déployées et validées dans le cadre d’un contrôle qualité ou un environnement d’évaluation exécutant la version cible d’AEM avant une mise à niveau de production.  

Généralités sur les recouvrements

Il est courant d’étendre la fonctionnalité prête à l’emploi d’AEM en superposant des nœuds et/ou des fichiers sous /libs avec d’autres nœuds sous /apps. Ces recouvrementsdoivent être suivis dans le contrôle de version et être testés avec la version cible d’AEM. Si un fichier (que ce soit, JS, JSP ou HTL) est superposé, il est recommandé de laisser un commentaire sur la fonctionnalité qui a été améliorée pour simplifier le test de régression de la version cible d’AEM. Vous trouverez plus d’informations sur les recouvrements en général ici. Des instructions sur les recouvremets spécifiques d’AEM figurent ci-dessous.

Les facettes de la recherche personnalisée requièrent certains réglages manuels après la mise à niveau pour fonctionner correctement. Pour plus d’informations, voir Mise à niveau des formulaires de recherche personnalisée.

Personnalisations de l’interface utilisateur d’Assets

Remarque :

Cette procédure n’est requise que pour les mises à niveau des versions d’AEM antérieures à 6.2.  

Les instances disposant de déploiements de ressources personnalisés doivent être préparées pour la mise à niveau. Cela permet de s’assurer que le contenu personnalisé est compatible avec la nouvelle structure de nœuds de la version 6.4.

Vous pouvez préparer les personnalisations de l’interface utilisateur d’Assets en procédant comme suit :

  1. Sur une instance qui doit être mise à niveau, ouvrez CRXDE Lite en accédant à http://server:port/crx/de/index.jsp

  2. Accédez au nœud suivant :

    • /apps/dam/content
  3. Renommez le nœud de contenu content_backup. Vous pouvez le faire en cliquant avec le bouton droit sur le volet d’exploration sur le côté gauche de la fenêtre, puis en choisissant Renommer.

  4. Une fois que le nœud a été renommé, créez un nœud de contenu sous /apps/dam nommé content et définissez son type de nœud sur Sling.Folder.

  5. Déplacez tous les nœuds enfants de content_backup vers le nœud de contenu que vous venez de créer. Vous pouvez le faire en cliquant avec le bouton droit sur chaque nœud enfant dans le volet d’exploration et en sélectionnant Déplacer.

  6. Supprimez le nœud content_backup.

  7. Les nœuds mis à jour sous /apps/dam avec le type de nœud correct sling:Folder doivent idéalement être enregistrés dans le contrôle de version et déployés avec la base de code ou au moins être sauvegardés en tant que modules de contenu

Génération d’identifiants pour les ressources existantes

Pour générer des identifiants pour les ressources existantes, mettez à jour les ressources en même temps que l’instance AEM pour exécuter la version 6.4. Cela nécessite d’activer la fonctionnalité Assets Insights. Pour plus de détails, reportez-vous à la section Ajout d’un code intégré.

Pour mettre à niveau les ressources, configurez le module d’identifiants de ressources associé dans la console JMX. En fonction du nombre de ressources dans le référentiel, migrateAllAssets peut prendre beaucoup de temps. Selon nos tests internes, cela peut prendre environ une heure pour 125 000 ressources sur TarMK.

1487758945977

Si vous avez besoin de plusieurs identifiants de ressources pour un sous-ensemble de vos ressources totales, utilisez l’API migrateAssetsAtPath.

Pour tout autre objectif, utilisez l’API migrateAllAssets()

Personnalisations de script InDesign

Adobe recommande de placer les scripts personnalisés à l’emplacement /apps/settings/dam/indesign/scripts. Pour en savoir plus sur les personnalisations de script InDesign, rendez-vous ici.

Récupération des configurations ContextHub

Les configurations ContextHub sont affectées par la mise à niveau. Des instructions sur la façon de récupérer les configurations ContextHub existantes sont disponibles ici.

Personnalisations des workflows

Il est courant de modifier les workflows prêts à l’emploi pour ajouter ou supprimer des fonctionnalités. Un workflow souvent personnalisé est le workflow Ressource de mise à jour de la gestion des actifs numériques. Tous les workflows nécessitant une implémentation personnalisée doivent être enregistrés et stockés dans le contrôle de version, car ils risquent d’être remplacés lors de la mise à niveau.  

Modèles modifiables

Remarque :

Cette procédure n’est requise que pour les mises à niveau de Sites à l’aide des modèles modifiables d’AEM 6.2

La structure des modèles modifiables a changé entre les versions 6.2 et 6.3 d’AEM. Si vous effectuez une mise à niveau à partir de la version 6.2 ou antérieure et si le contenu de votre site est créé à l’aide de modèles modifiables, vous devez utiliser l’outil de nettoyage de nœuds réactifs. L’outil est prévu pour fonctionner après une mise à niveau pour nettoyer le contenu. Il doit être exécuté sur les niveau d’auteur et de publication.

Modifications d’une implémentation de groupes d’utilisateurs fermés

L’implémentation des groupes d’utilisateurs fermés a considérablement évolué pour contourner les limitations de performance et d’évolutivité dans les versions précédentes d’AEM. La version précédente des groupes d’utilisateurs fermés a été abandonnée dans la version 6.3. En outre, la nouvelle implémentation est uniquement prise en charge dans l’interface utilisateur tactile. Si vous effectuez une mise à niveau à partir de la version 6.2 ou antérieure, vous trouverez les instructions de migration vers la nouvelle implémentation ici.  

Procédure de test

Un plan evaluation complet doit être préparé en vue de tester les mises à niveau. Le test de la base de code améliorée et de l’application doit être d’abord effectué dans des environnements inférieur. Tous les bugs détectés doivent être corrigés de manière itérative jusqu’à ce que la base de code soit stable. Ce n’est qu’à ce moment que les environnements de niveau supérieur doivent être mis à niveau.

Procédure de test de la mise à niveau

La procédure de mise à niveau, comme décrit ici, doit être testée sur des environnements de développement et de contrôle qualité, tel que cela est décrit dans votre runbook personnalisé (voir Planification de votre mise à niveau). La procédure de mise à niveau doit être répétée jusqu’à ce que toutes les étapes soient documentées dans le runbook de mise à niveau et que le processus de mise à niveau soit fluide.

Zones de test d’implémentation

Vous trouverez ci-dessous les domaines stratégiques de toute implémentation AEM devant être couverts par votre plan de tests une fois que l’environnement a été mis à niveau et que la base de code améliorée a été déployée.

Zone de test fonctionnelle Description
Sites publiés Test de l’implémentation d’AEM et du code associé sur le niveau de publication
via le dispatcher. Doit inclure des critères pour les mises à jour de la page et
l’invalidation du cache.
Création Test de votre implémentation d’AEM et du code associé sur le niveau d’auteur. Doit inclure la page, la création de composants et les boîtes de dialogue.
Intégrations des solutions with Marketing Cloud Validation des intégrations avec des produits comme Analytics, DTM et Target.
Intégration avec les systèmes tiers Toutes les intégrations tierces doivent être validées sur les niveaux d’auteur et de publication.
Authentification, sécurité et autorisations Tous les mécanismes d’authentification tels que LDAP/SAML doivent être validés.
Les autorisations et les groupes doivent être testés sur les niveaux d’auteur et de publication.
Requêtes Les index et les requêtes personnalisés doivent être testés, ainsi que la performance des requêtes.
Personnalisations de l’interface utilisateur Toutes les extensions ou personnalisations de l’interface utilisateur d’AEM dans l’environnement de création.
Workflows Fonctionnalités et workflows personnalisés et/ou prêts à l’emploi.
Test de performance Le test de chargement doit être effectué au niveau de l’auteur et de la publication qui simulent des scénarios réels.

Document de plan de tests et résultats

Vous devez créer un plan de tests qui couvre les zones de tests d’implémentation décrites ci-dessus. Dans la plupart des cas, il semble logique de séparer le protocole de test par des listes de tâche d’auteur et de publication. Ce plan de tests doit être effectué sur les environnements de développement, de contrôle qualité et d’évaluation avant de mettre à niveau les environnements de production. Les résultats des tests et les mesures de performance doivent être collectés dans des environnements inférieurs pour fournir une comparaison lors de la mise à niveau des environnements d’évaluation et de production.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne