Bonnes pratiques de gestion du code pour Adobe Commerce
Cette rubrique est conçue pour vous aider à décider d’utiliser Git ou le compositeur pour distribuer du code personnalisé, en prenant en compte la gestion des versions, la complexité du code et la gestion des dépendances.
Produits et versions concernés
Toutes les versions prises en charge de :
- Adobe Commerce sur les infrastructures cloud
- Adobe Commerce On-Premise
Définitions
- architecture de référence globale (GRA) également appelée architecture en marque blanche ou base de code commune. Il s’agit de l’architecture de distribution de module pour une configuration multi-instance.
- Configuration multi-instance : le même client utilise des installations Adobe Commerce distinctes pour des régions ou des marques distinctes. Chaque installation comporte des modules partagés ainsi que des modules uniques.
- Configuration d’instance unique : il n’existe 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 la gestion du code pour une configuration à instance unique
- Lorsque la base de code ne fera plus partie d’un GRA multi-marque à l’avenir
- Lorsque toutes les marques s’exécutent sur une seule instance en tant que sites web
- Le moment où la base de code peut ou va faire partie d’une configuration multi-instance à l’avenir
- Lorsque presque tous les modules sont interconnectés (non recommandé)
- Lorsque le code est conservé par une équipe qui ne connaît pas le compositeur
- Approche standard de la gestion du code pour une configuration multi-instance
- Lorsque Adobe conserve la base de code ou que l’équipe de maintenance connaît le compositeur
Matrice des fonctionnalités
chaque package Composer est représenté par un référentiel Git
app/vendor/vendor/ s’ils le sont via 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és limitées
composer.json
Solutions à éviter
-
Combinaison du compositeur et du
app/codepour vos modulesCombinez dans votre projet tous les inconvénients des deux styles de gestion de code. Cela ajoute une complexité, une instabilité et un manque de flexibilité inutiles.
Par exemple :
- Expliquez les workflows Git et Compositeur (au lieu de l’un d’eux uniquement) à l’équipe de développement.
- Installez les modules incompatibles dans
app/code, car rien n’est en place pour empêcher cela. - Le déplacement d’un module de
app/codevers le compositeur (ou inversement) est fastidieux, en particulier avec le développement en cours.
-
Gestionnaire de packages Satis
Le forfait privé coûte ± 600 € par an. Ce coût est pour l'ensemble de la GRA, et non 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 envoyez des validations à Git. Satis n'a pas non plus d'autorisation intégrée. Vous devez disposer d'un serveur Web pour exécuter Satis. Vous finissez par dépenser une multitude de frais d'abonnement de Packagiste Privé pour le maintien de Satis.
-
Commencez par Git, puis passez au compositeur
Choisissez une approche de gestion du code au début de votre projet. Le passage de Git au compositeur ou inversement, avec un développement en cours, est fastidieux et peut entraîner une perte de code et/ou une perte d’historique de révision.