Tecniche di implementazione dell'architettura di riferimento globale
Esistono diversi modi per ottimizzare il riutilizzo del codice con Adobe Commerce. Ognuna di queste quattro tecniche di implementazione presenta i propri vantaggi. Gli esempi in questo articolo sono ordinati da semplici a più complessi. Scegli la strategia più adatta al tuo progetto e alla roadmap futura. La migrazione da una strategia all'altra può richiedere molto tempo.
Quando utilizzare l’architettura di riferimento globale
L’architettura di riferimento globale può essere utile, a seconda del numero di istanze che possiedi. Un’istanza è un’installazione autonoma di Adobe Commerce che utilizza il proprio database. Contare il numero di database di produzione per conoscere il numero di istanze di cui si dispone. Se gestisci più di un’istanza o se prevedi questo scenario in futuro, puoi beneficiare dell’architettura di riferimento globale. Maggiore è il numero di funzionalità condivise dalle istanze, maggiore è il valore aggiunto da un'architettura di riferimento globale.
In uno di questi scenari, è consigliabile esplorare utilizzando più istanze di Adobe Commerce.
- Proprietari store diversi: se si gestisce il codice per più proprietari di store, ciascuno con il proprio archivio distinto, potrebbero essere necessarie istanze separate per mantenere efficacemente i singoli requisiti.
- Conformità alle normative nazionali: alcune normative impongono la memorizzazione dei dati dei clienti in aree geografiche specifiche. In tali casi, sono essenziali istanze separate per garantire il rispetto di tali regolamenti.
- Variazioni operative tra aree geografiche: l'utilizzo in più aree geografiche può comportare diversi programmi e requisiti di manutenzione. L’utilizzo di istanze separate offre flessibilità nella gestione efficiente di tali varianti.
- Vendite flash ad alta intensità: i negozi che effettuano vendite flash su larga scala richiedono spesso prestazioni server ottimizzate. L’infrastruttura dedicata fornita da istanze separate garantisce prestazioni ottimali in periodi di domanda così elevata.
- Differenze significative tra marchi o paesi: quando la differenza tra marchi o paesi è grande, l'utilizzo di una singola istanza determina il codice utilizzato solo per alcuni marchi o paesi. Istanze separate possono migliorare le prestazioni e la stabilità eliminando il codice non necessario per i marchi e i paesi che non ne hanno bisogno.
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.
