Documentation AEM as a Cloud Service Guide de l’utilisateur

Développer des sites avec le pipeline front-end developing-site-with-front-end-pipeline

Last update: Mon Jul 15 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Rubriques :
Développement

Créé pour :

Administration
Développeur

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.

TIP

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.

Contrat de création front-end front-end-build-contract

Tout comme l’environnement de création full-stack, le pipeline front-end possède son propre environnement. Les développeurs disposent d’une certaine flexibilité à l’aide de ce pipeline tant que le contrat de version front-end suivant est respecté.

Le pipeline front-end nécessite que le projet front-end Node.js utilise la directive de script build pour générer la version qu’il déploie. Cela est dû au fait que Cloud Manager utilise la commande npm run build pour générer le projet déployable pour la version front-end.

Le contenu obtenu du dossier dist est finalement déployé par Cloud Manager, sous la forme de fichiers statiques. Ces fichiers sont hébergés en externe sur AEM, mais sont disponibles via une URL /content/... sur l’environnement déployé.

Versions de Node node-versions

L’environnement de génération front-end prend en charge les versions suivantes de Node.js.

12
14 (par défaut)
16
18

Vous pouvez utiliser la NODE_VERSION variable d'environnement pour définir la version souhaitée.

Source unique de vérité single-source-of-truth

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 :

Le nom du module front-end, défini par la propriété 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.
Lorsqu’un module front-end partage le même référentiel Git avec d’autres modules, le nom de son dossier doit être égal au module front-end ou contenir le même nom. Par exemple, si le module front-end est nommé wknd-theme, le nom du dossier englobant se présente comme suit : wknd-theme-sources.
Le nom du pipeline front-end de Cloud Manager doit également contenir le nom du module front-end et ajouter également l’environnement auquel il déploie (production ou développement). Par exemple, pour le module front-end nommé wknd-theme, le nom du pipeline peut être wknd-theme-prod.

Une telle convention devrait éviter efficacement les erreurs de déploiement suivantes :

Application d’un module front-end au mauvais site.
Création de plusieurs modules front-end qui s’appliquent au même site, qui se remplaceraient les uns les autres.
Création de plusieurs pipelines front-end pour les mêmes sources, ce qui pourrait entraîner des conditions de concurrence, sans garantir l’ordre des déploiements.

Séparation des préoccupations separation-of-concerns

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.

L’équipe back-end configure d’abord un environnement de développement avec la nouvelle sortie HTML et/ou JSON.
1. Par le biais du pipeline de pile complète, ils déploient le code nécessaire pour effectuer le rendu de la nouvelle sortie HTML et/ou JSON souhaitée.
2. S’il s’agit d’un environnement auquel l’équipe front-end n’avait pas auparavant accès, les étapes suivantes doivent être effectuées.
  1. URL : l’équipe front-end doit connaître l’URL de cet environnement de développement.
  2. ACL : l’équipe front-end doit disposer d’un utilisateur AEM local disposant de droits similaires à ceux des « Contributeurs ».
  3. Git : l’équipe front-end doit disposer d’un emplacement Git distinct pour le module front-end qui cible spécifiquement cet environnement de développement.
    - Une pratique courante consiste à créer une branche 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.
  4. Pipeline : l’équipe front-end doit disposer d’un pipeline front-end qui se déploie vers l’environnement de développement. Ce pipeline déploierait le module front-end qui se trouve généralement dans la branche dev, comme décrit dans le point précédent.
L’équipe front-end fait ensuite en sorte que le code CSS et JS fonctionne avec l’ancienne et la nouvelle sortie.
1. Comme d’habitude, à développer localement :
  1. La commande 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.
  2. La configuration de la variable AEM_URL dans le fichier caché .env permet de contrôler à partir de quel environnement AEM le serveur proxy local consomme le contenu.
  3. La modification de la valeur de l’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.
  4. Il doit fonctionner à la fois avec l’environnement de développement qui effectue le rendu de la nouvelle sortie ainsi qu’avec l’environnement de production qui effectue le rendu de l’ancienne sortie.
2. Le travail front-end est terminé lorsque le module front-end mis à jour fonctionne pour les deux environnements et est déployé sur les deux.
L’équipe back-end peut ensuite mettre à jour l’environnement de production en déployant le code qui effectue le rendu de la nouvelle sortie HTML et/ou JSON via le pipeline de pile complète.
L’équipe front-end peut alors nettoyer ses CSS et JS et supprimer les éléments uniquement nécessaires à l’ancienne sortie, en déployant cette dernière mise à jour vers la production via le pipeline front-end.

Ressources supplémentaires additional-resources

Thèmes de site - Découvrez comment les thèmes de site AEM peuvent être utilisés pour personnaliser le style et la conception de votre site.
AEM Créateur de thèmes de site - Adobe fournit un Créateur de thèmes de site AEM sous la forme d’un ensemble de scripts permettant de créer des thèmes de site.

recommendation-more-help

fbcff2a9-b6fe-4574-b04a-21e75df764ab