DocumentationCommerceManuel d’implémentation

Bonnes pratiques relatives à la gestion du code pour Adobe Commerce

Last update: Mon Nov 25 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Créé pour :

  • Expérimenté
  • Développeur

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.

NOTE
Ces bonnes pratiques sont mieux adaptées aux migrations et aux implémentations, moins au développement de modules uniques.

Produits et versions concernés

Toutes les versions prises en charge de :

  • Adobe Commerce sur l’infrastructure cloud
  • Adobe Commerce sur site

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

Code géré principalement par Git
Code géré principalement via le compositeur
Quand utiliser pour une configuration d’instance unique
  • 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
Quand utiliser une configuration multi-instances
  • 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

Fonctionnalité
Git
Compositeur
Référentiel de code principal
Tout le code réside dans un seul référentiel Git ou dans quelques référentiels Git
Tout le code réside dans les modules d’un référentiel de compositeur
Chaque module de compositeur est représenté par un référentiel Git.
Emplacement du code
Le développement se produit dans le répertoire app/
Le développement se produit dans le répertoire vendor/
Gestion des mises à niveau Core
Adobe Commerce Core est installé et mis à niveau à l’aide du compositeur, le résultat est validé dans Git
Adobe Commerce Core est installé et mis à niveau à l’aide du compositeur ; le résultat est validé dans Git.
Gestion de modules tiers
Les modules tiers sont installés dans vendor/ s’ils sont installés via le marketplace ou packagist.org. Sinon, ils sont installés dans app/.
Tous les modules tiers sont installés dans le répertoire vendor/
Versions
La libération est caractérisée par des commandes git merge et git pull ou git checkout
La libération est caractérisée par des commandes composer update et git pull ou git checkout
Nombre de référentiels Git
Peu
Beaucoup
Complexité du développement
Simple
Complexe
Complexité de requête de tirage
Simple
Complexe
Complexité de la révision du code
Simple
Simple
Complexité de la mise à jour de l’environnement Dev/QA/UAT
Simple
Complexe
Prise en charge GRA
Icône Oui
Icône Oui
Les modules peuvent installer automatiquement des bibliothèques externes.
Aucune icône
Icône Oui
Flexibilité dans la composition de l'Armée de terre
Aucune icône
Icône Oui
Gestion des dépendances des modules
Icône Oui Uniquement via module.xml, fonctionnalité limitée
Icône Oui Gestion complète des dépendances via composer.json
Contrôle de version des modules
Icône Oui Vous pouvez définir une version, mais vous ne pouvez pas installer une version spécifique.
Icône Oui Prise en charge complète de la version
Services payants nécessaires
Référentiel Git
Référentiel Git, Packagist privé (+ 600 € par an)
Intégration de Bitbucket avec Jira possible
Icône Oui
Icône Oui
Modifications du code immédiatement disponibles pour l’installation
Icône Oui
Icône Oui

Solutions à éviter

  1. Combinaison du compositeur et app/code pour vos modules

    Vous 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/code vers le compositeur (ou à l’inverse) est fastidieux, en particulier avec le développement en cours.

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

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

recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60