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 oeuvre doivent être étudiés et résolus.

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. Sur la base des observations effectuées dans le test, il peut y avoir des moyens d’optimiser le code personnalisé. Cela peut inclure la refactorisation du code pour éviter de parcourir le référentiel, l’indexation personnalisée pour optimiser la recherche ou l’utilisation de noeuds non ordonnés dans JCR, entre autres.

Outre la possibilité de mettre à niveau votre base de code et vos personnalisations pour 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, comme décrit dans la section 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 upgrade-code-base

Création d’une branche spécifique pour la version 6.4 du code dans le contrôle de version create-a-dedicated-branch-for-6-4-code-in-version-control

Tous le code et toutes les configurations requis pour votre mise en oeuvre AEM doivent être gérés à l’aide d’une forme de contrôle de version. Une branche dédiée au contrôle de version 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 de AEM et les correctifs de bogues ultérieurs seront 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, la version du fichier Uber Jar doit être modifiée pour pointer 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, toutes les dépendances d’API d’AEM individuelles doivent être supprimées et remplacées par une seule inclusion du fichier Uber Jar pour la version cible d’AEM. La base de code doit ensuite être recompilée par rapport à la nouvelle version du fichier Uber Jar. Toutes les API ou méthodes obsolètes doivent être mises à 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>

Suppression 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 ont été déconseillées pour des raisons de sécurité, car elles offrent un niveau d’accès trop large. Dans les versions futures de Sling, ces méthodes seront supprimées.. Il est vivement recommandé de refactoriser tout code pour utiliser les utilisateurs du service à la place. Informations supplémentaires sur les utilisateurs de services et Découvrez comment supprimer progressivement les sessions administratives ici.

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 qui effectuent une mise à niveau à partir de Jackrabbit 2 (versions d’AEM antérieures à la version 6.0), cette opération est particulièrement importante, car Oak n’indexe pas le contenu automatiquement et des index personnalisés peuvent avoir besoin d’être créé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 pourraient affecter les requêtes existantes.

Plusieurs outils d’analyse et d’inspection des performances des requêtes sont disponibles :

Création d’interfaces utilisateur classiques classic-ui-authoring

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. Pour 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 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 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, consultez la section 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 le contrôle de version ou au minimum sauvegardée 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.

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

Il est courant d’étendre AEM fonctionnalité prête à l’emploi en superposant des noeuds et/ou des fichiers sous /libs avec des noeuds supplémentaires sous /apps. Ces recouvrements doivent être suivis dans le contrôle de version et testés par rapport à la version cible d’AEM. Si un fichier (qu’il s’agisse de JS, JSP ou HTL) est recouvert, il est recommandé 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. Vous trouverez plus d’informations sur les superpositions en général here. Vous trouverez ci-dessous des instructions relatives à des incrustations 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 d’Assets assets-ui-customizations

Les instances qui ont des déploiements de ressources personnalisés doivent être préparées pour la mise à niveau. Cela est nécessaire pour garantir que tout le contenu personnalisé est compatible avec la nouvelle structure de noeuds 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 à 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 d’informations, voir Ajout de code incorporé.

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 nos tests internes, 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 here.

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

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

Personnalisations des workflows workflow-customizations

Il est courant de mettre à jour 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 la variable Outil de nettoyage des noeuds réactifs. L’outil est destiné à être exécuté. after une mise à niveau pour nettoyer le contenu. Il doit être exécuté sur les niveaux Auteur et Publication.

Modifications de l’implémentation des CUG 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 du CUG a été abandonnée dans la version 6.3 et la nouvelle mise en oeuvre n’est prise en charge que 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 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 mise à niveau doit d’abord être effectué dans les environnements inférieurs. Tous les bogues détectés doivent être corrigés de manière itérative jusqu’à ce que la base de code soit stable. C’est seulement à cette condition que 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 d’implémentation implementation-test-areas-

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

Plan et résultats de test du document 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. Dans de nombreux cas, il est logique de séparer le plan de test par les listes de tâches Auteur et Publier . 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 capturés dans des environnements inférieurs afin de fournir une comparaison lors de la mise à niveau des environnements d’évaluation et de production.