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.
Prodotti e versioni interessati
Tutte le versioni supportate di:
- Adobe Commerce sull’infrastruttura cloud
- Adobe Commerce on-premise
Copre sia l'architettura di riferimento globale (GRA) che le installazioni di singole istanze.
Definizioni
- Global Reference Architecture (GRA): noto 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 distinti. Ogni installazione dispone di moduli condivisi e univoci.
- Installazione a istanza singola: è disponibile 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
- 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 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
Ogni singolo pacchetto Composer è rappresentato da un repository Git
app/vendor/vendor/ se sono installati tramite il marketplace o packagist.org. Altrimenti sono installati in app/vendor/git merge e git pull o git checkout comandicomposer update e git pull o git checkout comandi
module.xml, funzionalità limitata
composer.json
Soluzioni da evitare
-
Compositore combinato e
app/codeper i moduliComporta 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/codepoiché non è disponibile alcuna risorsa per impedire che ciò accada. - Lo spostamento di un modulo da
app/codea Compositore (o viceversa) è complicato, soprattutto con lo sviluppo in corso.
-
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.
-
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.