Contribution Tony Evers, architecte technique principal, Adobe
Techniques de mise en œuvre de l’architecture de référence globale
- Rubriques :
- Bonnes pratiques
- Configuration
Créé pour :
- Débutant
- Intermédiaire
- Développeur
- Utilisateur ou utilisatrice
- Leader
Il existe plusieurs façons d’optimiser la réutilisation du code avec Adobe Commerce. Ces quatre techniques de mise en œuvre présentent chacune leurs avantages propres. Les exemples de cet article sont classés de simples à plus complexes. Choisissez la stratégie qui correspond le mieux à votre projet et à la feuille de route future. La migration d’une stratégie vers une autre peut prendre du temps.
Quand utiliser l’architecture de référence globale
L’architecture de référence globale peut s’avérer utile, selon le nombre d’instances que vous possédez. Une instance est une installation autonome d’Adobe Commerce utilisant sa propre base de données. Comptez le nombre de bases de données de production pour connaître le nombre d’instances que vous possédez. Si vous conservez plusieurs instances ou si vous envisagez ce scénario à l’avenir, vous pouvez bénéficier d’une architecture de référence globale. Plus les instances partagent de fonctionnalités, plus une architecture de référence globale ajoute de valeur.
Dans l’un de ces scénarios, il est conseillé d’explorer l’utilisation de plusieurs instances d’Adobe Commerce.
- Différents propriétaires de boutique : si vous conservez du code pour plusieurs propriétaires de boutique, chacun ayant sa propre boutique, des instances distinctes peuvent être nécessaires pour gérer efficacement leurs besoins individuels.
- Conformité aux réglementations nationales : certaines réglementations exigent que les données clients soient stockées dans des régions spécifiques. Dans de tels cas, des instances distinctes sont essentielles pour assurer le respect de ces règlements.
- Variances opérationnelles entre les régions géographiques : l'exploitation dans plusieurs régions peut entraîner des calendriers et des exigences de maintenance différents. L’utilisation d’instances distinctes offre une certaine souplesse dans la gestion efficace de ces variations.
- Ventes de Flashs à haute intensité : les magasins qui réalisent des ventes flash à grande échelle nécessitent souvent des performances de serveur optimisées. Une infrastructure dédiée fournie par des instances distinctes garantit des performances optimales pendant ces périodes de forte demande.
- Différences significatives entre les marques ou les pays : lorsque la différence entre les marques ou les pays est importante, l’utilisation d’une seule instance entraîne l’utilisation d’un code uniquement pour certaines marques ou certains pays. Des instances distinctes peuvent améliorer les performances et la stabilité en éliminant le code inutile pour les marques et les pays qui n’en ont pas besoin.
Modèles d’architecture de référence globale
À côté de « aucun motif GRA », il existe quatre styles de motifs GRA.
Aucun modèle GRA
Lorsqu’aucun modèle GRA n’est utilisé, chaque instance Adobe Commerce est une application unique. Il n’y a pas de réutilisation du code, sauf en déplaçant manuellement le code d’une instance à une autre. Ces copies divergent toujours. La quantité d’effort nécessaire pour s’assurer que chaque instance comporte les mêmes modifications mais fonctionne toujours comme prévu peut devenir écrasante. Dans ce scénario, trois instances nécessitent trois fois plus d’efforts de maintenance qu’une seule instance.
Modèle Git GRA fractionné
Ce modèle se compose de référentiels Git pour le développement et d’un référentiel Git par instance. Chaque fichier de l’instance est conservé dans l’un des référentiels de développement. Ils se rassemblent en une tresse formant l'ensemble de la GRA. Chaque ligne de code n’existe que dans un seul référentiel de développement et est installée sur les instances à l’aide de la technique de tressage, ce qui entraîne la réutilisation du code.
Modèle GRA des packages en masse
Les modules principaux Adobe Commerce et tiers sont directement installés via les référentiels du compositeur. Les référentiels Git peuvent être utilisés comme référentiels de compositeur. Dans ce modèle, l’ensemble de la base de code partagée GRA est hébergé dans un ou plusieurs référentiels Git et installé via le compositeur. La caractéristique clé est que plusieurs modules, modules linguistiques ou thèmes sont hébergés dans un seul package de compositeur, ce qui simplifie le développement.
Le modèle GRA des packages distincts
Chaque module, module linguistique ou thème d’Adobe Commerce est installé en tant que package de compositeur distinct. Chaque personnalisation possède son propre référentiel Git. Cela se traduit par une flexibilité maximale dans la composition des instances et offre une gestion fiable des dépendances du compositeur. Pour l’optimisation des performances, tous les packages sont mis en miroir dans un seul référentiel de compositeur privé.
Modèle GRA monorepo
Tous les développements ont lieu dans un seul référentiel de code. L’automatisation génère des packages pour les nouvelles versions et les publie dans un référentiel de compositeur. Le modèle combine la faible surcharge de développement de l’approche des packages en bloc avec la flexibilité de l’approche des packages distincts. Le modèle monorepo est également idéal pour exécuter des tests fonctionnels automatisés.
Choisir un modèle GRA
Le choix d'un modèle GRA se fait en évaluant la complexité du projet, le besoin de flexibilité et la capacité d'adaptation de l'équipe de développement.
Il est préférable que les équipes peu expérimentées dans Adobe Commerce commencent simplement. Toutefois, si le projet nécessite un modèle GRA plus complexe en raison de ses caractéristiques, ne faites aucun compromis.
Caractéristiques communes du projet liées à chaque modèle :
-
Pas de modèle GRA : instance unique d’Adobe Commerce sans plan d’extension. Plusieurs instances d’Adobe Commerce avec un minimum de points communs.
-
Modèle Git partagé : les équipes qui souhaitent éviter le compositeur pour leurs personnalisations, dans la plupart des cas le modèle de packages en bloc est un modèle préféré au modèle Git partagé.
-
Modèle GRA de package en masse : base de code de personnalisation avec une interdépendance élevée. Les instances ont toutes des combinaisons très similaires de packages personnalisés. Aucune promotion ou rétrogradation fréquente des packages individuels. Équipes peu expérimentées dans la gestion de code et ayant besoin de simplicité.
-
Modèle GRA de packages distinct : une gestion flexible de la portée de publication est nécessaire. 50 packages personnalisés ou moins sont prévus dans les 5 prochaines années. Éventuellement, couches mondiales et régionales de code commun. Aucun plan de migration vers un modèle Monorepo. L’équipe est techniquement compétente et respecte strictement les processus.
-
Modèle GRA Monorepo : toutes les caractéristiques du modèle GRA des emballages séparés. Plus de 50 forfaits sont prévus au cours des cinq prochaines années. Besoin de tests automatisés approfondis. Prise en charge des environnements éphémères. Base de code complexe à l’échelle de l’entreprise qui doit évoluer sans augmenter les coûts de maintenance à un taux égal.
Le coût d’un mauvais choix
La migration d’un modèle à un autre est possible. Le diagramme ci-dessous montre le niveau d’impact du passage d’un modèle à un autre. Les lignes vertes montrent un impact faible, les lignes jaunes et ambres montrent des migrations modérément complexes à complexes.