Adobe Experience Manager (AEM) est un vaste système de gestion de contenu web pour entreprises. Il regorge de fonctionnalités qui permettent à un auteur de contenu de créer des expériences digitales impressionnantes.
Comme pour chaque produit d’une telle envergure, il est très facile de prendre une mauvaise décision. AEM est un produit très flexible, qui permet de réaliser un grand nombre d’adaptations. Par conséquent, chaque exigence peut être mise en œuvre par une multitude d’implémentations, allant d’une solution adaptée indépendante de la base d’AEM à une solution solidement intégrée avec la base du produit.
Adobe Experience Manager n’est pas une plateforme site web de base quelconque
Grâce à notre longue expérience dans la gestion de contenu web pour entreprises et l’utilisation d’AEM, nous sommes conscients de tous les obstacles liés au choix des différentes solutions proposées. Nous connaissons d’autant plus l’idée cachée derrière le produit, qui nous mène à choisir les solutions d’avenir les plus rentables et durables.
Dans l’article suivant, nous soulignerons les facteurs clés qui vous mèneront au succès dans le cadre de projets de développement de sites web dans AEM 6.3.
#1 La conception et l’architecture
Evaluez soigneusement chaque exigence et vérifiez-les avec les fonctionnalités du produit. Vous devrez parfois adapter les exigences de base, pour que les capacités d’AEM correspondent parfaitement au résultat désiré. Ci-dessous, quelques exemples :
- Exploitez le framework « Context-Aware Configuration », pour changer l’apparence et le comportement de sous-parties du site web.
- Le « rendering » de listes de documents qui proviennent d’un système externe à travers le framework « Sling Dynamic Include », afin de pouvoir stocker les pages qui les contiennent.
- L’utilisation du « Sling Resource Merger » pour éviter la duplication d’éléments prêts à être déployés.
- L’élimination du « responsive CSS » et l’exploitation des fonctionnalités internes d’AEM.
- La suppression complète de certaines exigences qui ne correspondent pas à l’idée du produit AEM.
- La possibilité de stockage de 95+% des demandes, afin d’assurer une haute performance.
#2 Utilisation des « WCM Core Components »
Vers la fin de l’année 2015, Adobe avait lancé une initiative nommée « WCM Core Components ». L’idée consistait à s’éloigner des anciens éléments « foundation », qui n’étaient plus à la hauteur des meilleures pratiques développées, et aussi à fournir une base solide grâce à laquelle chaque projet pourrait progresser.
L’exploitation de ces éléments sans adaptations fournit des blocs de données « single-responsibility » aux auteurs de contenu. Sur la base de ces éléments essentiels, nous avons aussi développé nos propres éléments essentiels (spécifiques à un projet). Lors de nos projets d’expérience digitale, nous avons activement contribué aux « WCM Core Components », pour les rendre encore plus performants.
En utilisant ces éléments et en exploitant l’idée de base, nous sommes capables de mettre en place une base du code très flexible et avons, par ailleurs, obtenu la possibilité d’améliorer les éléments un par un, sans briser leur fonctionnalité.
#3 Modèles modifiables (« Editable Templates »)
Auparavant, la tâche de mettre à disposition des modèles pour les auteurs de contenu revenait aux développeurs. Par le passé, un développeur créait (codait) un modèle et le mettait en place dans AEM. Ensuite, un auteur de contenu pouvait utiliser ce modèle pour créer une page basée sur celui-ci.
Dans AEM 6.2, une nouvelle fonction nommée « Editable Templates » avait été introduite. Elle permettait aux auteurs de contenu d’assembler eux-mêmes des modèles en utilisant l’interface tactile (« Touch UI »). Ainsi, un développeur n’était plus nécessaire pour effectuer cette « tâche de configuration ».
#4 AEM « Responsive Grid » et « Style System »
En utilisant le nouvel AEM « Responsive grid » en combinaison avec le « Style System » récent, les auteurs de contenu ont la possibilité de préciser directement dans le contenu comment les différents éléments vont se comporter sur différentes tailles d’écran.
Par le passé, les flux de travail traditionnels pour rendre le contenu réactif exigeaient du graphiste qu’il crée des maquettes des différents points de rupture. Ensuite, le développeur devait les implémenter pour un modèle particulier pour que l’auteur de contenu puisse sélectionner celui-ci pour y introduire le contenu. Avec la nouvelle édition de mise en page réactive, le flux de travail a été simplifié : l’auteur incorpore le contenu et a la possibilité d’adapter la mise en page indépendamment, sans devoir consulter les développeurs au sujet de la réactivité ou attendre que de futurs déploiements soient mis en place. Cette nouvelle fonction d’AEM 6.3 offre davantage de flexibilité aux auteurs, sans nécessiter de développeurs pour effectuer ces tâches. Finalement, plus aucun développement (ni déploiement) n’est requis pour modifier un modèle.
#5 Meilleures pratiques dans le développement web
Il existe des meilleures pratiques globales dans le développement, ainsi que des standards AEM particuliers, que nous imposons à travers tous les projets AEM. Ci-dessous, quelques exemples :
- Qui brise le « build » le répare.
- Des tests d’unité et d’intégration sont requis pour chaque nouvelle fonctionnalité.
- L’utilisation de « feature branches ».
- Les « merge requests » doivent être envoyées lorsqu'une « feature branch » est terminée.
- Un « peer-review » doit être effectué par un responsable technique.
- Pour le développement d’éléments, les « Sling Models » doivent être utilisés – même si l’élément est de conception basique.
- Le nouveau « resourceType-parameter » doit être utilisé avec « Sling Models ».
- Utilisation du « Proxy Component Pattern ».
- La documentation utilisateur et technique doit être constamment mise à jour.
- Le code doit être testé sur AEM et doit passer par le « Dispatcher ».
- La duplication du code est refusée, les règles « SonarQube » sont configurées, chaque « build » déclenche un scan « SonarQube », etc.
#6 Automatisation totale
Nous faisons tout notre possible pour tout automatiser. Nous utilisons « Puppet » (outil de configuration de gestion de logiciels) pour automatiser la mise en place de serveurs, autant que nos environnements locaux. Cela signifie que chaque développeur peut être opérationnel en peu de temps, en travaillant dans un environnement similaire à celui de la production. Cette configuration contient même un « Dispatcher » local pour assurer immédiatement l’enregistrement d’obstacles liés au stockage.
Chaque fois qu’un changement dans le code est effectué, il est vérifié par notre système de contrôle de version, un « build » est exécuté via « Jenkins » (outil d’intégration continuel), pour immédiatement prévenir les développeurs si un problème se pose. Selon la branche qui reçoit un code, un déploiement sera effectué sur l’environnement applicable, pour que les modifications soient immédiatement présentes sur ce système.
En appliquant le principe « Git Flow », nous sommes extrêmement flexibles avec la mise à jour de nos versions. Cette démarche est totalement automatisée. Le déploiement dans l’environnement de production nécessite uniquement l’actionnement d’un bouton (et c’est tout).
Conclusion
L’élément clé consiste à connaître les meilleures pratiques spécifiques au développement web via le WCMS avec lequel vous travaillez. Il est probablement d’autant plus important d’avoir quelqu’un à vos côtés qui les connaît et qui peut les imposer au sein de votre équipe de projet. Ceci est essentiel pour le succès de votre projet d’expérience digitale. Ces lignes directrices sont précieuses lorsqu’il s’agit de la mise en place de nouveaux sites web avec AEM, mais vous pouvez déjà commencer à les appliquer lorsque vous prévoyez des mises à niveau ou des expansions de votre plateforme Adobe actuelle. Maintenir cette solution stable et à jour ne devrait poser aucun problème.
Updated