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
- AEM Analyzer - Exécutez l’analyseur AEM comme décrit dans la planification de la mise à niveau et dans les détails sur la page Évaluation de la complexité de la mise à niveau avec AEM Analyzer. Vous obtenez un rapport AEM Analyzer qui contient plus de détails sur les zones qui doivent être traitées en plus des API/lots indisponibles dans la version cible d’AEM. Le rapport AEM Analyzer vous donne une indication des incompatibilités éventuelles de votre code. S’il n’en existe pas, votre déploiement est déjà compatible avec 6.5 LTS. Vous pouvez toujours choisir d’effectuer un nouveau développement pour utiliser la fonctionnalité LTS 6.5, mais vous n’en avez pas besoin uniquement pour maintenir la compatibilité.
- Développement de la base de code pour LTS 6.5- Créez une branche ou 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.
- Compilation avec 6.5 LTS Uber jar- Mettez à jour les POM de la base de code pour pointer vers 6.5 LTS Uber jar et compilez le code en fonction de celui-ci.
- Déploiement vers l’environnement LTS 6.5 - Une instance AEM 6.5 LTS (auteur + publication) nette doit être conservée dans un environnement Dev/QA. La base de code à jour et un échantillon représentatif de contenu (de l’exploitation actuelle) doivent être déployés.
- Validation du contrôle qualité et correction des bogues - Le contrôle qualité doit valider l’application sur les instances de création et de publication d’ 6.5 LTS . Tous les bugs détectés doivent être corrigés et intégrés dans la base de code 6.5 LTS. Répétez le cycle de développement jusqu’à ce que tous les bugs soient corrigés.
Avant de procéder à la mise à niveau, vous devez disposer d’une base de code d’application stable qui a été minutieusement testée par rapport à AEM 6.5 LTS.
Mise à niveau de la base de code upgrade-code-base
Création d’une branche dédiée pour le code LTS 6.5 dans le contrôle de version create-a-dedicated-branch-for-6.5-lts-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 d’Uber Jar afin qu’elle pointe vers la version 6.5 LTS d’AEM. Mettez à jour toutes les API ou méthodes obsolètes afin qu’elles soient compatibles avec la version cible d’AEM. Recompilez la base de code sur la nouvelle version d’Uber Jar.
<dependency>
<groupId>com.adobe.aem</groupId>
<artifactId>uber-jar</artifactId>
<version>6.6.0</version>
<classifier>apis</classifier>
<scope>provided</scope>
</dependency>
Uber Jars pour AEM 6.5
uber-jar-6.5.x.jar: contient toutes les API publiques d’AEM 6.5.uber-jar-6.5.x-apis-with-deprecations.jar- Inclut les API publiques et les API obsolètes d’AEM 6.5.
Uber Jars pour AEM 6.5 LTS
Pour AEM 6.5 LTS, il existe à nouveau deux types de fichiers Uber Jars :
uber-jar-6.6.x-apis.jar: contient toutes les API publiques d’AEM 6.5 LTS.uber-jar-6.6.x-deprecated-apis.jar- Inclut uniquement les API obsolètes d’AEM 6.5 LTS.
Principale différence : AEM 6.5 par rapport à AEM 6.5 LTS Uber Jars
- Dans AEM 6.5, si des API publiques et obsolètes sont nécessaires, vous pouvez utiliser inclure un seul fichier jar,
uber-jar-6.5.x-apis-with-deprecations.jardans votre fichierpom.xml. - Dans AEM 6.5 LTS, si vous avez besoin à la fois d’API publiques et obsolètes, vous devez inclure deux fichiers jar distincts,
uber-jar-6.6.x-apis.jarpour les API publiques etuber-jar-6.6.x-deprecated-apis.jarpour les API obsolètes.
Coordonnées Maven pour le fichier Jar des API obsolètes
<dependency>
<groupId>com.adobe.aem</groupId>
<artifactId>uber-jar</artifactId>
<version>6.6.0</version>
<classifier>deprecated-apis</classifier>
<scope>provided</scope>
</dependency>
Notes du développeur developer-notes
- Le LTS AEM 6.5 n’inclut pas de bibliothèque Google guava prête à l’emploi. La version requise peut être installée selon les besoins.
- Le bundle Sling XSS utilise désormais la bibliothèque Java HTML Sanitizer et l’utilisation de la méthode
XSSAPI#filterHTML()doit être utilisée pour effectuer le rendu du contenu HTML en toute sécurité et non pour transmettre des données à d’autres API.
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-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.