Modèles d’architecture de référence globale

À côté de « aucun motif GRA », il existe quatre styles de motifs GRA.

5 icônes de motifs GRA : pas de GRA, split, bulk, separée et monorepo.

Aucun modèle GRA

Icône représentant « pas de 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.

Diagramme représentant 3 magasins, où chacun est une copie du premier, avec un développement unique se produisant dans les 3 copies.

Modèle Git GRA fractionné

Icône représentant le modèle GRA « partagé »

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.

Diagramme indiquant où le code est stocké dans un modèle de répartition GRA

Modèle GRA des packages en masse

Icône représentant le modèle GRA « en bloc »

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.

Diagramme indiquant où le code est stocké dans un modèle GRA de packages en masse

Le modèle GRA des packages distincts

Icône représentant le modèle GRA « 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é.

Diagramme indiquant où le code est stocké dans un modèle GRA de packages distinct

Modèle GRA monorepo

Icône représentant le 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.

Diagramme indiquant où le code est stocké dans un modèle GRA monorepo

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 :

  1. 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.

  2. 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é.

  3. 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é.

  4. 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.

  5. 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.