Comprendre le multi-location et le développement simultané

Présentation

Lorsque plusieurs équipes déploient leur code dans les mêmes environnements AEM, il existe des pratiques qu’elles doivent suivre pour s’assurer que les équipes peuvent travailler aussi indépendamment que possible, sans intervenir sur les orteils des autres équipes. Bien qu'elles ne puissent jamais être entièrement éliminées, ces techniques minimiseront les dépendances entre équipes. Pour qu’un modèle de développement simultané réussisse, une bonne communication entre les équipes de développement est essentielle.

En outre, lorsque plusieurs équipes de développement travaillent sur le même environnement AEM, il y a probablement un certain degré de multi-location en jeu. Beaucoup de choses ont été écrites sur les considérations pratiques à prendre en compte pour appuyer plusieurs locataires dans un environnement AEM, en particulier sur les défis à relever dans la gestion de la gouvernance, des opérations et du développement. Cet article explore certains des défis techniques liés à l’implémentation d’AEM dans un environnement multi-locataires, mais bon nombre de ces recommandations s’appliqueront à toute organisation comptant plusieurs équipes de développement.

Il est important de noter que, bien qu’AEM puisse prendre en charge plusieurs sites et même plusieurs marques déployées sur un seul environnement, elle ne propose pas de véritable multi-location. Certaines configurations d’environnement et ressources système seront toujours partagées sur tous les sites déployés sur un environnement. Le présent article fournit des conseils pour minimiser l'impact de ces ressources partagées et offre des suggestions pour rationaliser la communication et la collaboration dans ces domaines.

Avantages et défis

La mise en oeuvre d’un environnement multi-locataire présente de nombreux défis.

Celles-ci comprennent :

  • Complexité technique supplémentaire
  • Augmentation des frais de développement
  • Dépendances inter-organisations sur les ressources partagées
  • Complexité opérationnelle accrue

Malgré les difficultés rencontrées, l’exécution d’une application multi-tenant présente des avantages, tels que :

  • Réduction des coûts matériels
  • Réduction du temps de mise sur le marché pour les sites futurs
  • Réduction des coûts de mise en oeuvre pour les futurs clients
  • Architecture standard et pratiques de développement dans l’entreprise
  • Un code base commun

Si l’entreprise nécessite une connexion multi-clients réelle, sans connaissance préalable des autres clients et sans code partagé, contenu ou auteurs communs, alors les instances d’auteur distinctes sont la seule option viable. L’augmentation globale de l’effort de développement doit être comparée aux économies réalisées en termes d’infrastructures et de coûts de licence afin de déterminer si cette approche est la plus adaptée.

Techniques de développement

Gestion des dépendances

Lors de la gestion des dépendances de projet Maven, il est important que toutes les équipes utilisent la même version d’un lot OSGi donné sur le serveur. Pour illustrer ce qui peut mal se passer lorsque les projets Maven sont mal gérés, nous présentons un exemple :

Le projet A dépend de la version 1.0 de la bibliothèque, foo ; foo version 1.0 est incorporé dans leur déploiement sur le serveur . Le projet B dépend de la version 1.1 de la bibliothèque foo ; foo version 1.1 est incorporé dans leur déploiement.

En outre, supposons qu’une API ait changé dans cette bibliothèque entre les versions 1.0 et 1.1. À ce stade, l’un de ces deux projets ne fonctionnera plus correctement.

Pour résoudre ce problème, nous vous recommandons de créer tous les enfants des projets Maven d’un seul projet de réacteur parent. Ce projet de réacteur a deux objectifs : il permet la création et le déploiement de tous les projets ensemble si vous le souhaitez, et contient les déclarations de dépendance pour tous les projets enfants. Le projet parent définit les dépendances et leurs versions, tandis que les projets enfants ne déclarent que les dépendances dont ils ont besoin, héritant de la version du projet parent.

Dans ce scénario, si l’équipe qui travaille sur le projet B nécessite des fonctionnalités dans la version 1.1 de foo, il devient rapidement évident dans l’environnement de développement que cette modification va rompre le projet A. À ce stade, les équipes peuvent discuter de cette modification et rendre le projet A compatible avec la nouvelle version ou rechercher une autre solution pour le projet B.

Notez que cela n’élimine pas la nécessité pour ces équipes de partager cette dépendance. Cela met en évidence les problèmes rapidement et rapidement afin que les équipes puissent discuter des risques éventuels et s’entendre sur une solution.

Prévention de la duplication du code

Lorsque vous travaillez sur plusieurs projets, il est important de s’assurer que le code n’est pas dupliqué. La duplication de code augmente la probabilité d’occurrences de défaut, le coût des modifications du système et la rigidité globale dans la base de code. Pour éviter la duplication, refactorisez la logique commune en bibliothèques réutilisables pouvant être utilisées dans plusieurs projets.

Pour répondre à ce besoin, nous recommandons le développement et la maintenance d’un projet principal dont toutes les équipes peuvent dépendre et y contribuer. Pour ce faire, il est important de s’assurer que ce projet de base ne dépend, à son tour, d’aucun des projets des équipes individuelles ; cela permet un déploiement indépendant tout en continuant à promouvoir la réutilisation du code.

Voici quelques exemples de code qui se trouvent généralement dans un module principal :

  • Configurations à l’échelle du système, telles que :
    • Configurations OSGi
    • Filtres de servlet
    • Mappages ResourceResolver
    • Pipelines Sling Transformer
    • Gestionnaires d’erreurs (ou utilisez ACS AEM Commons Error Page Handler1)
    • Servlets d’autorisation pour la mise en cache sensible aux autorisations
  • Classes utilitaires
  • Logique métier principale
  • Logique d’intégration tierce
  • Superpositions de l’interface utilisateur de création
  • Autres personnalisations requises pour la création, telles que les widgets personnalisés
  • Lanceurs de workflow
  • Éléments de conception courants utilisés sur plusieurs sites

Architecture de projet modulaire

Cela n’élimine pas la nécessité pour plusieurs équipes de dépendre et potentiellement de mettre à jour le même ensemble de code. En créant un projet de base, nous avons réduit la taille du code de base qui est partagé entre les équipes qui diminuent, mais sans éliminer le besoin de ressources partagées.

Pour que les modifications apportées à ce module principal ne perturbent pas les fonctionnalités du système, nous recommandons qu’un développeur ou une équipe de développeurs chargée d’effectuer cette tâche assure la supervision. Une option consiste à disposer d’une équipe unique qui gère toutes les modifications apportées à ce module ; une autre consiste à demander aux équipes d’envoyer des demandes d’extraction qui sont examinées et fusionnées par ces ressources. Il est important qu’un modèle de gouvernance soit conçu et accepté par les équipes et que les développeurs le suivent.

Gestion de la portée du déploiement&nbsp

Lorsque différentes équipes déploient leur code dans le même référentiel, il est important qu’elles ne remplacent pas les modifications de l’autre. AEM dispose d’un mécanisme pour contrôler cela lors du déploiement des packages de contenu, le filtre . fichier xml. Il est important qu’il n’y ait pas de chevauchement entre les filtres. fichiers xml, sinon le déploiement d’une équipe risque d’effacer le déploiement précédent d’une autre équipe. Pour illustrer ce point, reportez-vous aux exemples suivants de fichiers de filtre bien conçus ou problématiques :

/apps/my-company ou /apps/my-company/my-site

/etc/clientlibs/my-company ou /etc/clientlibs/my-company/my-site

/etc/designs/my-company ou /etc/designs/my-company/my-site

Si chaque équipe configure explicitement son fichier de filtrage en fonction du ou des sites sur lesquels elle travaille, chacune d’elles peut déployer ses composants, ses bibliothèques clientes et ses conceptions de site indépendamment sans effacer les modifications de l’autre.

Puisqu’il s’agit d’un chemin d’accès global au système et qu’il n’est pas spécifique à un site, la servlet suivante doit être incluse dans le projet principal, car les modifications apportées ici peuvent avoir un impact potentiel sur n’importe quelle équipe :

/apps/sling/servlet/errorhandler

Recouvrements

Les superpositions sont fréquemment utilisées pour étendre ou remplacer la fonctionnalité d’AEM prête à l’emploi, mais l’utilisation d’une superposition affecte l’ensemble de l’application AEM (c’est-à-dire que toutes les modifications de fonctionnalités seront disponibles pour tous les clients). Cela serait plus compliqué si les clients avaient des exigences différentes pour la superposition. Idéalement, les groupes d’affaires doivent collaborer pour s’entendre sur la fonctionnalité et l’aspect des consoles administratives d’AEM.

Si un consensus ne peut être atteint entre les différentes unités opérationnelles, une solution possible serait simplement de ne pas utiliser de superpositions. Créez plutôt une copie personnalisée de la fonctionnalité et exposez-la via un chemin différent pour chaque client. Cela permet à chaque client d’avoir une expérience utilisateur complètement différente, mais cette approche augmente le coût de mise en oeuvre et les efforts de mise à niveau ultérieurs.

Lanceurs de workflow

AEM utilise des lanceurs de workflow pour déclencher automatiquement l’exécution du workflow lorsque des modifications spécifiées sont apportées au référentiel. AEM fournit plusieurs lanceurs prêts à l’emploi, par exemple pour exécuter des processus de génération de rendu et d’extraction de métadonnées sur des ressources nouvelles et mises à jour. Bien qu’il soit possible de laisser ces lanceurs tels quels, dans un environnement multi-locataires, si les clients ont des exigences de lanceur et/ou de modèle de workflow différentes, il est probable que des lanceurs individuels devront être créés et gérés pour chaque client. Ces lanceurs devront être configurés pour s’exécuter sur les mises à jour de leur client tout en laissant intacte le contenu d’autres clients. Pour ce faire, appliquez facilement des lanceurs aux chemins de référentiel spécifiés spécifiques au client.

URL de redirection vers un microsite

AEM fournit une fonctionnalité d’URL de redirection vers un microsite qui peut être définie sur une base par page. Dans un scénario multi-locataires, cette approche pose problème : AEM ne garantit pas l’unicité entre les URL de redirection vers un microsite configurées de cette manière. Si deux utilisateurs différents configurent le même chemin Vanity pour différentes pages, un comportement inattendu peut être rencontré. Pour cette raison, nous vous recommandons d’utiliser les règles mod_rewrite dans les instances de Dispatcher Apache, ce qui permet un point central de configuration, en plus des règles de résolveur de ressource sortant uniquement.

Groupes de composants

Lors du développement de composants et de modèles pour plusieurs groupes de création, il est important d’utiliser efficacement les propriétés componentGroup et allowedPaths. En les exploitant efficacement avec les conceptions de site, nous pouvons nous assurer que les auteurs de la marque A ne voient que les composants et les modèles créés pour leur site, tandis que les auteurs de la marque B ne voient que les leurs.

Tests

Bien qu’une bonne architecture et des canaux de communication ouverts puissent contribuer à empêcher l’introduction de défauts dans des zones inattendues du site, ces approches ne sont pas infaillibles. C’est pourquoi il est important de tester entièrement ce qui est déployé sur la plateforme avant de publier quoi que ce soit en production. Cela nécessite une coordination entre les équipes sur leurs cycles de publication et renforce la nécessité d’une suite de tests automatisés couvrant autant de fonctionnalités que possible. En outre, comme un système sera partagé par plusieurs équipes, les performances, la sécurité et les tests de charge deviennent plus importants que jamais.

Considérations opérationnelles

Ressources partagées

AEM s’exécute dans une seule JVM ; toutes les applications AEM déployées partagent intrinsèquement des ressources les unes avec les autres, en plus des ressources déjà consommées lors de l’exécution normale d’AEM. Dans l’espace JVM lui-même, il n’y aura pas de séparation logique des threads, et les ressources limitées disponibles pour AEM, telles que la mémoire, le processeur et l’i/o du disque, seront également partagées. Tout client qui consomme des ressources affectera inévitablement d’autres clients système.

Performances

Si vous ne suivez pas AEM bonnes pratiques, il est possible de développer des applications qui consomment des ressources au-delà de ce qui est considéré comme normal. Par exemple, cela déclenche de nombreuses opérations de workflow lourdes (telles que la mise à jour de gestion des actifs numériques), l’utilisation des opérations Push-on-modify MSM sur de nombreux noeuds ou l’utilisation de requêtes JCR coûteuses pour le rendu du contenu en temps réel. Cela aura inévitablement un impact sur les performances d’autres applications client.

Journalisation

AEM fournit des interfaces prêtes à l’emploi pour une configuration de journalisation robuste qui peut être utilisée à notre avantage dans les scénarios de développement partagé. En spécifiant des enregistreurs distincts pour chaque marque, par nom de package, nous pouvons obtenir un certain degré de séparation des logs. Bien que les opérations à l’échelle du système telles que la réplication et l’authentification soient toujours consignées à un emplacement central, le code personnalisé non partagé peut être consigné séparément, ce qui facilite la surveillance et le débogage pour l’équipe technique de chaque marque.

Sauvegarde et restauration

En raison de la nature du référentiel JCR, les sauvegardes traditionnelles fonctionnent sur l’ensemble du référentiel, plutôt que sur un chemin de contenu individuel. Il n’est donc pas possible de séparer facilement les sauvegardes par client. À l’inverse, la restauration à partir d’une sauvegarde permet de restaurer le contenu et les noeuds du référentiel pour tous les clients du système. Bien qu’il soit possible d’effectuer des sauvegardes de contenu ciblées à l’aide d’outils tels que VLT ou de sélectionner du contenu à restaurer en créant un package dans un environnement distinct, ces opérations
Les approches ne prennent pas facilement en compte les paramètres de configuration ou la logique de l’application et peuvent être fastidieuses à gérer.

Considérations relatives à la sécurité

Listes ACL

Il est bien sûr possible d’utiliser des listes de contrôle d’accès (ACL) pour contrôler qui a accès à l’affichage, la création et la suppression de contenu en fonction des chemins de contenu, ce qui nécessite la création et la gestion des groupes d’utilisateurs. La difficulté à gérer les listes de contrôle d’accès et les groupes dépend de l’importance accordée à ce que chaque client n’ait aucune connaissance des autres et de la nécessité pour les applications déployées de compter sur des ressources partagées. Pour assurer l’efficacité de l’administration des listes de contrôle d’accès, des utilisateurs et des groupes, nous vous recommandons de disposer d’un groupe centralisé avec la supervision nécessaire pour vous assurer que ces contrôles d’accès et entités de sécurité se chevauchent (ou ne se chevauchent pas) d’une manière qui favorise l’efficacité et la sécurité.

Sur cette page