Mettre à jour le code et les personnalisations upgrading-code-and-customizations

Lors de la planification d’une mise à niveau, les aspects suivants d’une mise en œuvre doivent être étudiés et abordés.

Présentation overview

Avant de procéder à une mise à niveau, vous devez disposer d’une base de code d’application stable qui a été soigneusement testée par rapport à la version cible d’AEM. En fonction des observations effectuées dans les tests, il peut être possible d’optimiser le code personnalisé. Par exemple, il peut être possible de refactoriser le code pour éviter de parcourir le référentiel, d’indexer de manière personnalisée pour optimiser la recherche ou d’utiliser ded noeuds non ordonnés dans JCR, entre autres.

Outre la mise à niveau facultative de votre base de code et de vos personnalisations pour qu’elles fonctionnent avec la nouvelle version d’AEM, la version 6.5 permet de gérer plus efficacement vos personnalisations à l’aide de la fonctionnalité de compatibilité descendante, comme décrit dans Compatibilité descendante dans AEM 6.5.

Comme mentionné ci-dessus et illustré dans le diagramme ci-dessous, en exécutant le Détecteur de motifs dans la première étape, vous pouvez évaluer la complexité globale de la mise à niveau. Il peut également vous aider à décider si vous souhaitez exécuter le mode de compatibilité ou mettre à jour vos personnalisations pour utiliser toutes les nouvelles fonctionnalités d’AEM 6.5. Pour en savoir plus, consultez la page Compatibilité descendante dans AEM 6.5.

Mise à niveau de la base de code upgrade-code-base

Création d’une branche dédiée pour le code de la version 6.5 dans la gestion de versions create-a-dedicated-branch-for-6.5-code-in-version-control

Tout le code et toutes les configurations nécessaires pour votre mise en oeuvre d’AEM doivent être gérés à l’aide d’une forme de gestion de versions. Une branche dédiée à la gestion de versions doit être créée pour gérer les modifications nécessaires pour la base de code dans la version cible d’AEM. Les tests itératifs de la base de code par rapport à la version cible d’AEM et les correctifs de bugs ultérieurs sont gérés dans cette branche.

Mise à jour de la version AEM Uber Jar update-the-aem-uber-jar-version

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 recommandé d’inclure Uber Jar en tant que dépendance unique au lieu d’inclure les dépendances d’API d’AEM individuelles. Lors de la mise à niveau de la base de code, modifiez la version du fichier Uber Jar pour qu’elle pointe vers la version cible d’AEM. Si votre projet a été développé sur une version d’AEM antérieure à l’existence d’Uber Jar, supprimez toutes les dépendances d’API d’AEM individuelles. Remplacez-les par une seule inclusion du fichier Uber Jar pour la version cible d’AEM. Recompilez la base de code par rapport à la nouvelle version du fichier Uber Jar. Mettez à jour les API ou méthodes obsolètes afin qu’elles soient compatibles avec la version cible d’AEM.

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

Suppression progressive de l’utilisation du résolveur de ressources d’administration phase-out-use-of-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 sont désormais déconseillées pour des raisons de sécurité, car elles offrent un niveau d’accès trop large. Ces méthodes seront supprimées des prochaines versions de Sling.. Il est vivement recommandé de refactoriser tout code pour utiliser les utilisateurs et utilisatrices du service à la place. Pour plus d’informations sur les utilisateurs et utilisatrices du service et sur la manière d’éliminer progressivement les sessions administratives, voir Utilisateurs et utilisatrices du service dans Adobe Experience Manager (AEM).

Requêtes et index Oak queries-and-oak-indexes

Toute utilisation de requêtes dans la base de code doit être minutieusement testée dans le cadre de la mise à niveau de la base de code. Pour les clients effectuant une mise à niveau à partir de Jackrabbit 2 (versions d’AEM antérieures à la version 6.0), ce test est particulièrement important, car Oak n’indexe pas le contenu automatiquement et vous devez créer des index personnalisés. Si vous effectuez une mise à niveau à partir d’une version 6.x d’AEM, les définitions d’index Oak prêtes à l’emploi peuvent avoir changé et peuvent avoir un impact sur les requêtes existantes.

Les outils suivants sont disponibles pour l’analyse et l’inspection des performances des requêtes :

Création dans l’interface utilisateur classique classic-ui-authoring

La création de l’IU classique est toujours disponible dans AEM 6.5, mais elle sera bientôt obsolète. Voir Fonctionnalités obsolètes et supprimées pour plus d’informations. Si votre application s’exécute dans l’environnement de création de l’interface utilisateur classique, il est recommandé de passer à AEM 6.5 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 AEM 6.5, plusieurs configurations OSGi doivent être intégrées à la base de code. Vous trouverez plus d’informations sur la procédure de configuration sous Activer l’accès à l’IU classique.

Alignement avec la structure de référentiel de la version 6.5 align-repository-structure

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 auparavant le cas. 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 aem-customizations

Toutes les personnalisations de l’environnement de création AEM dans la version source d’AEM doivent être identifiées. Une fois identifiées, il est recommandé de stocker chaque personnalisation dans la gestion de versions ou, au minimum, de les sauvegarder dans un package 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 d’exploitation.

Recouvrements en général overlays-in-general

Il est courant d’étendre les fonctionnalités d’AEM prêtes à l’emploi en recouvrant des nœuds et/ou des fichiers sous /libs avec des nœuds supplémentaires sous /apps. Ces recouvrements doivent faire l’objet d’un suivi dans le cadre de la gestion de versions et d’un test par rapport à la version cible d’AEM. Si un fichier (JS, JSP, HTL, par exemple) est superposé, Adobe vous recommande de laisser un commentaire sur les fonctionnalités qui ont été améliorées pour simplifier les tests de régression sur la version cible d’AEM. Voir Recouvrements pour obtenir des informations génériques. Vous trouverez ci-dessous des instructions relatives à des recouvrements d’AEM spécifiques.

Mettre à niveau les formulaires de recherche personnalisés upgrading-custom-search-forms

Les facettes de recherche personnalisées nécessitent quelques ajustements manuels après la mise à niveau pour fonctionner correctement. Pour en savoir plus, consultez la section Mise à niveau des formulaires de recherche personnalisée.

Personnalisations de l’interface utilisateur Assets assets-ui-customizations

Les instances qui ont des déploiements d’Assets personnalisés doivent être préparées pour la mise à niveau. Cette action est nécessaire pour s’assurer que tout 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 :

Génération d’identifiants pour les ressources existantes generating-asset-ids-for-existing-assets

Pour générer des identifiants pour les ressources existantes, mettez à niveau les ressources en même temps que l’instance AEM pour exécuter la version 6.5d’AEM. Cela requiert l’activation de la fonctionnalité Assets Insights. Pour plus de détails, consultez la section Ajout d’un code intégré.

Pour mettre à niveau les ressources, configurez le package 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 les tests internes d’Adobe, cela peut prendre environ une heure pour 125 000 ressources sur TarMK.

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 indesign-script-customizations

Adobe recommande de placer les scripts personnalisés à l’emplacement /apps/settings/dam/indesign/scripts. Vous trouverez plus d’informations sur les personnalisations des scripts d’InDesign sous Intégrer Adobe Experience Manager Assets à Adobe InDesign Server.

Récupérer des configurations ContextHub recovering-contexthub-configurations

Les configurations ContextHub sont affectées par la mise à niveau. Voir Configurer ContextHub pour obtenir des instructions sur la manière de récupérer les configurations ContextHub existantes.

Personnalisations des workflows workflow-customizations

Il est courant de modifier les workflows prêts à l’emploi pour ajouter ou supprimer des fonctionnalités inutiles. Un workflow qui est souvent personnalisé est le workflow Ressource de mise à jour de la gestion des ressources 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 editable-templates

La structure des modèles modifiables a changé entre AEM 6.2 et 6.3. 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 des noeuds réactifs. L’outil est destiné à être exécuté après une mise à niveau pour nettoyer le contenu. Exécutez-le sur les niveaux de création et de publication.

Modifications de l’implémentation des groupes d’utilisateurs fermés cug-implementation-changes

L’implémentation des groupes d’utilisateurs fermés a considérablement changé pour répondre aux limites de performances et d’évolutivité des versions précédentes d’AEM. La version précédente des groupes fermés d’utilisateurs et utilisatrices a été abandonnée dans la version 6.3 et la nouvelle implémentation n’est prise en charge que dans l’interface d’utilisation tactile.

Procédure de test testing-procedure

Un plan de test complet doit être préparé pour tester les mises à niveau. Le test de la base de code et de l’application mises à niveau doit d’abord être effectué dans les environnements inférieurs. Tous les bugs détectés doivent être corrigés itérativement jusqu’à ce que la base de code soit stable, après quoi les environnements de niveau supérieur doivent être mis à niveau.

Test de la procédure de mise à niveau testing-the-upgrade-procedure

La procédure de mise à niveau décrite ici doit être testée sur les environnements de développement et d’assurance qualité, comme indiqué dans votre runbook personnalisé (voir Planification de la 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 de l’implémentation implementation-test-areas-

Vous trouverez ci-dessous les zones critiques de toute implémentation d’AEM qui doivent être couvertes par votre plan de test une fois l’environnement mis à niveau et la base de code mise à niveau déployée.

Documentation du plan de test et des résultats document-test-plan-and-results

Vous devez créer un plan de tests qui couvre les zones de tests d’implémentation décrites ci-dessus. Souvent, il est logique de séparer le plan de test par les listes de tâches de création et de publication. Ce plan de test doit être exécuté sur les environnements de développement, d’assurance qualité et d’évaluation avant la mise à niveau des environnements de production. Les résultats de test et les mesures de performances doivent être enregistrés dans des environnements inférieurs afin de fournir une comparaison lors de la mise à niveau des environnements d’évaluation et de production.