Grâce au pipeline front-end, les développeurs front-end bénéficient d’une plus grande indépendance et le processus de développement peut gagner considérablement en rapidité. Ce document décrit le fonctionnement de ce processus, ainsi que certaines considérations à prendre en compte pour tirer pleinement parti de ce processus.
Si vous ne connaissez pas encore l’utilisation du pipeline front-end et les avantages qu’il peut apporter, consultez le parcours de création rapide de site pour savoir comment déployer rapidement un nouveau site et personnaliser son thème de manière totalement indépendante du développement back-end.
Tout comme l’environnement de création full-stack, le pipeline front-end possède son propre environnement. Les développeurs et développeuses disposent d’une certaine flexibilité dans ce pipeline tant que le contrat de création front-end suivant est respecté.
Le pipeline front-end requiert le projet front-end Node.js pour utiliser la directive de script build
afin de générer la version déployée par le pipeline front-end. C’est-à-dire que Cloud Manager utilise la commande npm run build
pour générer le projet déployable dans le dossier dist
.
Le contenu du dossier dist
est ce qui est finalement déployé vers AEM as a Cloud Service à partir du pipeline Cloud Manager.
Par défaut, le pipeline front-end utilise Node 14, mais les versions 12 et 16 sont également disponibles.
Vous pouvez utiliser la variable d’environnement NODE_VERSION
pour définir la version souhaitée.
Une bonne pratique générale consiste à maintenir une source unique de vérité pour ce qui est déployé vers AEM. L’objectif de Cloud Manager est de rendre cette source unique de vérité évidente. Cependant, comme le pipeline front-end permet de découpler l’emplacement de certains éléments du code, une certaine responsabilité supplémentaire incombe à la configuration correcte des pipelines front-end. Veillez à ne pas créer plusieurs pipelines front-end qui se déploient sur le même site dans le même environnement.
C’est pourquoi, et surtout lorsque plusieurs pipelines front-end sont créés, il est recommandé de maintenir une convention de dénomination systématique telle que la suivante :
name
du fichier package.json
, doit contenir le nom du site auquel il s’applique. Par exemple, pour un site situé à l’adresse /content/wknd
, le nom du module front-end se présente comme suit : wknd-theme
.wknd-theme
, le nom du dossier englobant se présente comme suit : wknd-theme-sources
.wknd-theme
, le nom du pipeline peut être wknd-theme-prod
.Une telle convention devrait éviter efficacement les erreurs de déploiement suivantes :
Une autre bonne pratique qui s’applique à toute séparation des préoccupations est d’apporter une attention particulière à la manière dont le contrat qui sépare les préoccupations est conçu et géré. Dans le cas du pipeline front-end, le contrat qui sépare ce code du reste est le HTML et le JSON rendus par le site. Si ce HTML et JSON restent stables, le pipeline front-end offre sa valeur maximale en rendant l’équipe front-end totalement indépendante.
Il n’existe actuellement aucune fonctionnalité spécifique pour exécuter le pipeline de pile complète de manière synchrone avec le ou les pipelines front-end. C’est pourquoi, lorsque vous découplez le développement front-end du pipeline de pile complète, une attention particulière doit être apportée au contrat qui sépare ces deux domaines de préoccupation. Ce contrat correspond généralement au HTML et/ou au code JSON généré par Experience Manager. Les modifications apportées à ce contrat doivent donc être bien planifiées entre les équipes exploitant les différents pipelines afin qu’elles s’accordent sur la manière de séquencer les modifications correspondantes.
Les étapes suivantes sont généralement recommandées lorsqu’il est nécessaire d’apporter des modifications à la sortie HTML et/ou JSON ayant un impact sur les deux domaines de préoccupation.
dev
, afin que les modifications apportées à l’environnement de développement puissent ensuite être facilement fusionnées dans la branche main
à déployer dans l’environnement de production.dev
, comme décrit dans le point précédent.npx aem-site-theme-builder proxy
exécutée dans le module front-end démarre un serveur proxy permettant de demander le contenu d’un environnement AEM, tout en remplaçant les fichiers CSS et JS du module front-end par ceux du dossier local dist
.AEM_URL
dans le fichier caché .env
permet de contrôler à partir de quel environnement AEM le serveur proxy local consomme le contenu.AEM_URL
permet donc de basculer entre les environnements de production et de développement, afin d’ajuster les CSS et JS de sorte qu’ils s’adaptent aux deux environnements.