Dans la phase dʼimplémentation du parcours, vous découvrirez les outils à votre disposition pour préparer votre code et votre contenu pour la migration vers AEM as a Cloud Service.
Dans les parties précédentes du parcours, vous avez passé en revue vous familiariser avec les modifications apportées à AEM as a Cloud Service, et déterminé si votre déploiement est prêt à être déplacé dans le cloud avec la variable phase de préparation.
Votre parcours de migration continue dans cet article, qui propose des conseils sur la façon dʼutiliser les outils fournis par Adobe pour sʼassurer que votre code et contenu sont prêts à être migrés vers le cloud.
Ce document vise à vous fournir les éléments suivants :
Avant de commencer, vous devez vous familiariser avec Cloud Manager, car il s’agit du seul mécanisme de déploiement du code vers AEM as a Cloud Service.
Cloud Manager permet aux entreprises de gérer elles-mêmes AEM dans le cloud. Il comprend une structure d’intégration et de diffusion continues (CI/CD) qui permet aux équipes informatiques et aux partenaires d’implémentation d’accélérer la diffusion des personnalisations ou des mises à jour sans compromettre les performances ou la sécurité.
Pour vous familiariser avec l’utilisation de Cloud Manager, consultez les ressources suivantes :
Parcours d’intégration pour comprendre les ressources d’aide autonome sur l’intégration à Experience Manager as a Cloud Service.
Intégration de Git à Adobe Cloud Manager pour en savoir plus sur l’utilisation d’un référentiel Git unique pour déployer du code.
Configuration d’Adobe Experience as a Cloud Service pour en savoir plus sur la gestion des produits et de l’accès utilisateur dans Admin Console.
Les étapes exactes de votre transition vers Cloud Service dépendent des systèmes achetés et de vos pratiques de cycle de vie du développement logiciel.
La figure suivante montre les principales étapes de la phase de conversion de votre code et de votre contenu en vue de leur utilisation avec AEM as a Cloud Service :
Nous commencerons par détailler les outils à utiliser afin que vous puissiez y parvenir dans les chapitres ci-dessous.
Pour migrer le contenu de votre instance AEM actuelle vers l’instance Cloud Service, vous pouvez utiliser l’outil de transfert de contenu d’Adobe.
Il permet de spécifier le sous-ensemble de contenu que vous souhaitez transférer entre votre instance AEM source et l’instance AEM Cloud Service.
Le processus de migration de contenu consiste en plusieurs étapes, qui demandent une planification, un suivi et une collaboration entre les différentes équipes.
Pour plus d’informations sur le fonctionnement de l’outil et sur la façon dont Adobe vous recommande de l’utiliser, voir la section Documentation de l’outil de transfert de contenu.
À présent, il est temps de commencer à refactoriser les fonctionnalités existantes pour les rendre compatibles avec Cloud Service.
Tout d’abord, consultez la documentation détaillant les outils de base et commencez à restructurer votre code :
Vous pouvez également consulter les ressources suivantes :
Regardez cette vidéo pour comprendre comment installer le SDK Dispatcher localement :
Regardez cette vidéo pour comprendre comment configurer le SDK Dispatcher :
Développer et exécuter du code dans AEM as a Cloud Service nécessite un changement d’état d’esprit. Le code doit être résilient, d’autant plus qu’une instance peut être arrêtée à tout moment. Le code s’exécutant dans Cloud Service doit savoir qu’il s’exécute toujours dans une grappe. Cela signifie qu’il y a toujours plusieurs instances en cours d’exécution.
Certaines modifications sont nécessaires pour que les projets Maven d’AEM soient compatibles avec le cloud. AEM as a Cloud Service exige une séparation du contenu et du code dans des packages distincts pour le déploiement dans AEM :
/apps
et /libs
sont considérées comme des zones immuables d’AEM, car ils ne peuvent pas être modifiés après le démarrage d’AEM (c’est-à-dire au moment de l’exécution). Cela inclut les opérations de création, de mise à jour ou de suppression. Toute tentative de modification d’une zone immuable au moment de l’exécution échouera.
Toutes les autres zones du référentiel (par exemple, /content
, /conf
, /var
, /home
, /etc
, /oak:index
, /system
, /tmp
) sont toutes des zones modifiables, ce qui signifie qu’elles peuvent être modifiées au moment de l’exécution.
Pour en savoir plus, consultez la documentation sur la structure de package recommandée.
Adobe propose plusieurs outils pour accélérer certaines de vos tâches de refonte du code. La maîtrise de ces outils et des problèmes qu’ils résolvent, permet de réduire la complexité et la durée de la migration.
Une fois que vous avez configuré l’environnement de développement local, familiarisez-vous avec le SDK AEM as a Cloud Service en consultant la documentation.
Pour gérer le développement continu de votre code sur votre AEM active, ainsi que les tâches de refactorisation du code dans le cadre de votre parcours de transition, Adobe vous recommande de planifier une période de gel du code jusqu’à ce que vous ayez terminé la restructuration de votre projet Maven afin qu’il soit compatible avec AEM as a Cloud Service.
Une fois la restructuration du projet terminée, vous pouvez reprendre le développement de nouveau code à l’aide de cette nouvelle structure. Les défaillances du pipeline de Cloud Manager seront ainsi réduites au cours du déploiement et du test du code.
Les tâches de transfert de contenu et de refonte du code n’ont pas à être effectuées séquentiellement. et peuvent être réalisées indépendamment les unes des autres. Toutefois, une structure de projet appropriée est requise pour que le contenu soit correctement rendu dans votre environnement Cloud Service.
Le pipeline Cloud Manager prend en charge l’exécution de tests par rapport à l’environnement d’évaluation.
Suivez les bonnes pratiques des documents ci-dessous concernant les tests de qualité du code :
La préparation du système source pour la migration implique des tâches au niveau du système et de l’administrateur AEM. Vous pouvez commencer par vérifier que le référentiel de contenu est bien entretenu en contrôlant le nettoyage des révisions et l’état de la tâche de nettoyage de la mémoire d’entrepôt de données. Si vous exécutez la version 6.3 d’AEM (car l’outil de transfert de contenu est compatible à partir de la version 6.3), il est recommandé d’effectuer un compactage hors ligne, suivi du nettoyage de la mémoire d’entrepôt de données.
La vérification de la cohérence des données est recommandée pour toutes les versions d’AEM afin de s’assurer que le référentiel de contenu est en bon état pour lancer des activités de migration.
Un accès de niveau administrateur système est requis pour installer et configurer AZCopy.
Il est également recommandé de consulter toutes les ressources, pages, projets AEM, utilisateurs et groupes inutilisés afin de gagner du temps lors de la migration. Voir la section Santé du référentiel de contenu.
Une fois que l’accès à un clone de production est établi, il faut vérifier la santé du référentiel. Comme mentionné dans la section précédente, l’objectif est de nettoyer et de compacter le référentiel sur la source avant de démarrer la migration. Cette étape peut permettre de gagner beaucoup de temps autrement consacré à la résolution des problèmes une fois la migration commencée.
Action | Points clés |
---|---|
Utilisateurs, groupes et autorisations | Vous devez comprendre le volume d’utilisateurs, de groupes et la complexité autour des adhésions. Recherchez les occasions de nettoyer les utilisateurs et les groupes inutilisés dans la source avant la migration. |
Traitement des ressources incomplet | Essayez de terminer le traitement des ressources dans le système source avant de démarrer la migration afin d’éviter tout problème potentiel dans AEM as a Cloud Service après la migration. |
État du contenu | Il est recommandé de rechercher du contenu incorrect et de le purger avant de démarrer la migration. Par exemple, recherchez les ressources ou les pages qui n’ont pas de rendu original ou qui sont bloquées dans le traitement du processus. Voir aussi État de la ressource. |
La section Stratégie et chronologie de migration du contenu explique en détail comment extrapoler les données collectées et créer un plan de migration.
La collecte de données peut vous aider à planifier les activités de migration et les tâches associées. Les temps d’extraction et d’ingestion sont particulièrement utiles car les points de données peuvent être associés à une taille spécifique du jeu de migration. Par conséquent, ces points de données peuvent être extrapolés pour établir une formule :
Ces points de données peuvent également vous aider à établir des indicateurs clés de performance et autres tâches liées à la migration.
En fonction des points de données que vous avez collectés (voir ci-dessus), vous pouvez créer un plan de migration qui peut être intégré dans un plan de macro-projet. Cette étape permet à tous les principaux intervenants de visualiser et de planifier les activités de migration.
Le tableau suivant illustre un plan de migration type :
Itération de la migration | Date de début | Date de fin estimée | Dépendances | Durée estimée (en jours) | Détails supplémentaires / Actions |
---|---|---|---|---|---|
PRDCLONE-AUTEUR-INITIAL-USRMAP-CSSTAGE-AUTEUR | |||||
PRDCLONE-PUBLICATION-COMPLEMENT-CSSTAGE-AUTEUR |
Comme vous pouvez le voir dans le tableau ci-dessus, il est utile de suivre un format de dénomination spécifique pour identifier les itérations de migration, par exemple : PRDCLONE pour l’environnement AEM source, AUTEUR/PUBLICATION pour l’environnement AEM as a Cloud Service, CSSTAGE-AUTEUR pour l’instance AEM as a Cloud Service, etc.
Voici quelques détails importants qui influencent votre plan de migration :
Le nombre total d’extractions nécessaires
Nombre total des ingestions requises
Vous pouvez utiliser le suivi de la migration pour noter les durées de l’exécution initiale et de complément. Ces points de données vous aideront à formuler des exigences réalistes en matière de gel du contenu avant le complément final.
L’outil de suivi vous aidera également à :
Le tableau suivant illustre un suivi de migration fonctionnel :
Source (Environnement / Instance / URL) | Destination (Environnement / Instance / URL) | Nom du jeu de migration, type (initial ou complément) | Taille du jeu de migration (Mo) | Mappage utilisateur (Oui/Non) | Durée de l’extraction (Début, Fin, Temps pris) | Durée d’ingestion (Début, Fin, Temps pris) | Problèmes / Résolutions / Détails |
---|---|---|---|---|---|---|---|
La section suivante présente les étapes importantes et les tâches associées qui peuvent être utilisées pour formuler une stratégie et un calendrier de migration de contenu.
Une fois que vous avez entièrement compris comment évaluer si votre installation AEM est prête à être déplacée vers le cloud, alors que nous apprenons à utiliser les outils nécessaires pour la préparer, il est temps de passer au phase de activation.