Best practice per la gestione del codice per Adobe Commerce

Questo argomento è progettato per aiutarti a decidere se utilizzare Git o Composer per distribuire il codice personalizzato, tenendo in considerazione la gestione delle versioni, la complessità del codice e la gestione delle dipendenze.

NOTE
Queste best practice sono più adatte per le migrazioni e le implementazioni, meno per lo sviluppo di singoli moduli.

Prodotti e versioni interessati

Tutte le versioni supportate di:

  • Adobe Commerce sull’infrastruttura cloud
  • Adobe Commerce on-premise

Copre entrambi architettura di riferimento globale (GRA) e installazioni a istanza singola.

Definizioni

  • Architettura di riferimento globale (GRA): nota anche come White Label Architecture o Common Code Base. Si tratta dell’architettura di distribuzione del modulo per una configurazione a più istanze.
  • Configurazione a più istanze: lo stesso client utilizza installazioni Adobe Commerce separate per aree geografiche o marchi separati. Ogni installazione dispone di moduli condivisi e univoci.
  • Configurazione a istanza singola: esiste una sola installazione di Adobe Commerce. Possono esistere più copie del codice sorgente per diversi ambienti di test, ma esiste una sola versione del codice di produzione.

Quando utilizzare Git o Composer

Codice gestito principalmente tramite Git
Codice gestito principalmente tramite Composer
Quando utilizzare per una configurazione a istanza singola
  • Approccio standard per la gestione del codice per una configurazione a istanza singola
  • Quando la base di codice non farà parte di un GRA multi-brand in futuro
  • Quando tutti i brand vengono eseguiti su una singola istanza come siti web
  • Quando la base di codice può o diventerà parte di una configurazione con più istanze in futuro
Quando utilizzare per una configurazione con più istanze
  • Quando quasi tutti i moduli sono interconnessi (scelta non consigliata)
  • Quando il codice viene gestito da un team che non ha familiarità con Composer
  • Approccio standard per la gestione del codice per una configurazione con più istanze
  • Quando Adobe gestisce la base di codice o il team di manutenzione ha familiarità con Composer

Matrice di funzioni

Funzionalità
Git
Compositore
Archivio del codice principale
Tutto il codice risiede in un singolo archivio Git o in alcuni archivi Git
Tutto il codice risiede nei pacchetti in un archivio Compositore
Ogni singolo pacchetto Composer è rappresentato da un archivio Git
Posizione codice
Lo sviluppo avviene in app/ directory
Lo sviluppo avviene in vendor/ directory
Gestione degli aggiornamenti di base
Adobe Commerce Core viene installato e aggiornato tramite Composer, il risultato è confermato in Git
Adobe Commerce Core viene installato e aggiornato tramite Composer; il risultato viene confermato in Git
Gestione dei moduli di terze parti
I moduli di terze parti sono installati in vendor/ se vengono installati tramite il marketplace o packagist.org. Altrimenti vengono installati in app/
Tutti i moduli di terze parti sono installati nel vendor/ directory
Versioni
Il rilascio è caratterizzato da git merge e git pull o git checkout comandi
Il rilascio è caratterizzato da composer update e git pull o git checkout comandi
Numero di archivi Git
Pochi
Molti
Complessità dello sviluppo
Semplice
Complesso
Complessità della richiesta pull
Semplice
Complesso
Complessità della revisione del codice
Semplice
Semplice
Complessità dell’aggiornamento dell’ambiente di sviluppo/QA/UAT
Semplice
Complesso
Supporto GRA
Icona Sì
Icona Sì
I moduli possono installare automaticamente librerie esterne
Nessuna icona
Icona Sì
Flessibilità nella composizione del GRA
Nessuna icona
Icona Sì
Gestione delle dipendenze dei moduli
Icona Sì Solo tramite module.xml, funzionalità limitata
Icona Sì Gestione completa delle dipendenze tramite composer.json
Controllo delle versioni dei moduli
Icona Sì È possibile definire una versione, ma non installare una versione specifica
Icona Sì Supporto versione completa
Servizi a pagamento necessari
Archivio Git
Archivio Git, Packagist privato (± €600 all'anno)
È possibile integrare Bitbucket con Jira
Icona Sì
Icona Sì
Modifiche al codice immediatamente disponibili per l’installazione
Icona Sì
Icona Sì

Soluzioni da evitare

  1. Compositore e app/code per i moduli

    Comporta tutti gli svantaggi di entrambi gli stili di gestione del codice combinati nel progetto. Aggiunge inutili complessità, instabilità e mancanza di flessibilità.

    Ad esempio:

    • Spiega al team di sviluppo i flussi di lavoro Git e Compositore (anziché uno solo).
    • Installare moduli incompatibili in app/code poiché non c'è nulla che impedisca che ciò accada.
    • Spostamento di un modulo da app/code Compositore (o viceversa) è complicato, soprattutto con lo sviluppo in corso.
  2. Gestione pacchetti Satis

    Private Packagist costa ± €600 all'anno. Questo costo è per l'intero GRA combinato, non per marchio. Non cercare di evitare questi costi utilizzando la soluzione gratuita Satis. Satis non aggiorna automaticamente i pacchetti ogni volta che invii commit a Git. Anche Satis non ha un'autorizzazione incorporata. Per eseguire Satis, è necessario gestire un server Web. Alla fine si finisce per spendere una moltitudine della tassa di abbonamento a Private Packagist mantenendo Satis.

  3. Inizia con Git, quindi passa a Compositore

    Scegli un approccio di gestione del codice all’inizio del progetto. Il passaggio da Git a Compositore o viceversa, con lo sviluppo in corso, è complicato e potrebbe portare alla perdita di codice e/o di cronologia delle revisioni.

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