Modelli di architettura di riferimento globali
Accanto a "nessun pattern GRA" ci sono quattro stili di pattern GRA.
Nessun pattern GRA
Quando non si utilizza un pattern GRA, ogni istanza di Adobe Commerce è un’applicazione univoca. Non è possibile riutilizzare il codice, se non spostando manualmente il codice da un’istanza all’altra. Queste copie divergono sempre. La quantità di lavoro necessaria per garantire che ogni istanza abbia le stesse modifiche ma funzioni ancora come previsto può diventare travolgente. In questo scenario, tre istanze richiedono un impegno di manutenzione tre volte maggiore rispetto a una singola istanza.
Il pattern Git GRA diviso
Questo modello è costituito da archivi Git per lo sviluppo e da un archivio Git per istanza. Ogni file nell’istanza viene mantenuto in uno degli archivi di sviluppo. Si riuniscono come una treccia formando l'intero GRA. Ogni riga di codice esiste solo in un singolo archivio di sviluppo e viene installata nelle istanze utilizzando la tecnica di intreccio, determinando il riutilizzo del codice.
Il modello GRA dei pacchetti bulk
I moduli core e di terze parti di Adobe Commerce vengono installati direttamente tramite gli archivi del Compositore. Gli archivi Git possono essere utilizzati come archivi Compositore. In questo modello, l’intera base di codice condivisa GRA è ospitata in un singolo o in alcuni archivi Git e installata tramite Composer. La caratteristica chiave è che più moduli, Language Pack o temi sono ospitati in un unico pacchetto di compositore, semplificando lo sviluppo.
Il pattern GRA dei pacchetti separati
Ogni modulo, Language Pack o tema di Adobe Commerce viene installato come pacchetto del compositore separato. Ogni personalizzazione dispone di un proprio archivio Git. Ciò significa flessibilità finale nella composizione delle istanze e dispone di una gestione affidabile delle dipendenze del Compositore. Per ottimizzare le prestazioni, tutti i pacchetti vengono rispecchiati in un unico repository del compositore privato.
Il modello GRA monorepo
Tutto lo sviluppo avviene in un unico archivio di codice. L’automazione genera pacchetti per le nuove versioni e li pubblica in un archivio del compositore. Il modello combina il basso sovraccarico di sviluppo dell'approccio dei pacchetti di massa con la flessibilità dell'approccio dei pacchetti separati. Il modello monorepo è ideale anche per l’esecuzione di test funzionali automatizzati.
Scelta di un pattern GRA
La scelta di un modello GRA è fatta valutando la complessità del progetto, la necessità di flessibilità e la capacità di adattamento del team di sviluppo.
Per i team con poca esperienza Adobe Commerce, la cosa migliore è iniziare semplice. Tuttavia, se il progetto richiede un modello di GRA più complesso a causa delle sue caratteristiche, non compromettere.
Caratteristiche comuni del progetto relative a ciascun modello:
-
Nessun pattern GRA: singola istanza di Adobe Commerce senza piani di estensione. Più istanze di Adobe Commerce con compatibilità minima tra di esse.
-
Schema Git GRA diviso: team che desiderano evitare Composer per le proprie personalizzazioni; nella maggior parte dei casi, il pattern Bulk packages è quello preferito a Split Git.
-
Pattern GRA per pacchetto bulk: base di codice di personalizzazione con interdipendenza elevata. Tutte le istanze hanno combinazioni molto simili di pacchetti personalizzati. Nessuna promozione frequente o retrocessione di singoli pacchetti. Team con poca esperienza nella gestione del codice e che necessitano di semplicità.
-
Pattern GRA per pacchetti separati: è necessaria una gestione flessibile dell'ambito di rilascio. Sono previsti fino a 50 pacchetti personalizzati nei prossimi 5 anni. Livelli potenzialmente globali e regionali di codice comune. Nessun piano di migrazione a un modello Monorepo. Il team è tecnicamente esperto e ha una rigorosa aderenza al processo.
-
Modello GRA Monorepo: tutte le caratteristiche del modello GRA dei pacchetti separati. Nei prossimi 5 anni sono previsti più di 50 pacchetti. Necessità di test automatizzati estesi. Supporto per ambienti temporanei. Codebase complessa di scala aziendale che deve essere scalata senza scalare i costi di manutenzione a un tasso uguale.
Il costo di una scelta sbagliata
È possibile migrare da un modello all’altro. Il diagramma seguente mostra il livello di impatto del passaggio da un modello all'altro. Le linee verdi mostrano un impatto ridotto, mentre le linee gialle e ambrate mostrano migrazioni da moderatamente complesse a complesse.