Bonnes pratiques relatives à la gestion du code pour Adobe Commerce
Cette rubrique est conçue pour vous aider à décider si vous utilisez Git ou le compositeur pour distribuer du code personnalisé, en tenant compte de la gestion des versions, de la complexité du code et de la gestion des dépendances.
Produits et versions concernés
Toutes les versions prises en charge de :
- Adobe Commerce sur l’infrastructure cloud
- Adobe Commerce sur site
Il couvre à la fois les installations d’architecture de référence globale (GRA) et d’instance unique.
Définitions
- Architecture de référence globale (GRA) : également connue sous le nom d’architecture de libellé blanc ou de base de code commun. Il s’agit de l’architecture de distribution de module pour une configuration multi-instances.
- Configuration multi-instances : le même client utilise des installations Adobe Commerce distinctes pour des régions ou des marques distinctes. Chaque installation a partagé ainsi que des modules uniques.
- Configuration d’une seule instance : il n’y a qu’une seule installation Adobe Commerce. Plusieurs copies du code source peuvent exister pour différents environnements de test, mais il n’existe qu’une seule version du code de production.
Quand utiliser Git ou le compositeur
- Approche standard de gestion du code pour une configuration à instance unique
- Lorsque la base de code ne fera plus partie d’une GRA multimarque à l’avenir
- Lorsque toutes les marques s’exécutent sur une seule instance en tant que sites web
- Lorsque la base de code peut ou va faire partie d’une configuration multi-instances à l’avenir
- Lorsque la plupart des modules sont interconnectés (non recommandé)
- Lorsque le code est géré par une équipe qui ne connaît pas le compositeur d’expérience
- Approche standard pour la gestion du code pour une configuration multi-instances
- Lorsqu’Adobe conserve la base de code ou que l’équipe de maintenance connaît bien le compositeur
Matrice de fonctionnalités
Chaque module de compositeur est représenté par un référentiel Git.
app/vendor/vendor/ s’ils sont installés via le marketplace ou packagist.org. Sinon, ils sont installés dans app/.vendor/git merge et git pull ou git checkoutcomposer update et git pull ou git checkout
module.xml, fonctionnalité limitée
composer.json
Solutions à éviter
-
Combinaison du compositeur et
app/codepour vos modulesVous obtenez ainsi tous les inconvénients des deux styles de gestion du code combinés dans votre projet. Cela ajoute une complexité, une instabilité et un manque de flexibilité inutiles.
Par exemple :
- Expliquez les workflows Git et Composer (au lieu d’un seul d’entre eux) à l’équipe de développement.
- Installez les modules incompatibles dans
app/code, car rien n’est en place pour empêcher cela. - Déplacer un module de
app/codevers le compositeur (ou à l’inverse) est fastidieux, en particulier avec le développement en cours.
-
Gestionnaire de modules Satis
Private Packagist coûte + 600 € par an. Ce coût est pour l'ensemble de la GRA combinée, pas par marque. N'essayez pas d'éviter ces coûts en utilisant la solution gratuite Satis. Satis ne met pas automatiquement à jour vos packages chaque fois que vous poussez des validations sur git. Satis n'a pas non plus d'autorisation. Vous devez gérer un serveur web pour exécuter Satis. Vous finissez par dépenser une multitude des frais d'abonnement des Packagistes privés en conservant Satis.
-
Commencer avec Git, puis passer au compositeur
Choisissez une approche de gestion du code au début de votre projet. Passer de Git au compositeur ou inversement, avec un développement en cours est lourd et pourrait entraîner une perte de code et une perte d’historique de révision.