Intervento di Tony Evers, Sr. Technical Architect, Adobe
Schema dell’architettura di riferimento globale Monorepo
- Argomenti:
- Best practice
- Configurazione
Creato per:
- Esperto
- Sviluppatore
- Utente
- Leader
Questa guida spiega come configurare Adobe Commerce con il modello GRA (Monorepo Global Reference Architecture).
Il modello GRA Monorepo coinvolge un singolo archivio Git per ospitare tutte le personalizzazioni comuni. Questo singolo archivio Git viene esposto tramite Compositore come pacchetti di compositore separati.
Vantaggi e svantaggi di questo modello
Vantaggi:
- Ideale per test funzionali
- Riutilizzo del codice tramite archivi di codice condivisi
- Massima flessibilità nell'installazione dei pacchetti: ogni pacchetto GRA può essere aggiornato, aggiornato o supportato singolarmente
- Supporto completo per il controllo delle versioni semantiche
- Non sono necessari strumenti speciali, infrastrutture complesse o strategie speciali di ramificazione
- Supporto per tutti i tipi di pacchetti supportati da Composer
- Ideale per ambienti temporanei, che sono facoltativi, ma per team di distribuzione di volumi elevati sono molto utili
Svantaggi:
- Possibilità di distribuire combinazioni di pacchetti non sviluppati nella stessa configurazione, necessità di rigorose procedure di test
- Il modello GRA monorepo può essere complesso all'inizio. Assegna un lead che aiuti il team a lavorare con il sistema
Configurare Adobe Commerce con il pattern GRA per pacchetti separati
La struttura della directory
La struttura di directory finale di un’installazione completa di Adobe Commerce con il pattern GRA dei pacchetti separati presenta la seguente struttura di directory:
.
├── app/
│ └── etc/
│ └── config.php
├── packages/
│ └── ...
├── composer.json
└── composer.lock
Un archivio Git di produzione ha la seguente struttura di directory:
.
├── app/
│ └── etc/
│ └── config.php
├── composer.json
└── composer.lock
La differenza è che le istanze di produzione si installano da Composer, dove il monorepo conserva la propria copia di ogni pacchetto all’interno della directory dei pacchetti.
Preparare un archivio di produzione
Crea un archivio per la prima istanza di Adobe Commerce, che rappresenta un negozio web per il Brand X.
mkdir gra-monorepo-brand-x
cd gra-monorepo-brand-x
composer create-project --repository-url=https://repo.magento.com/ magento/project-enterprise-edition .
git init
git remote add origin git@github.com:AntonEvers/gra-monorepo-brand-x.git
git add composer.json composer.lock
git commit -m 'initialize Brand X repository'
git push -u origin main
Installa Adobe Commerce con bin/magento setup:install. Eseguire il commit dei file app/etc/config.php e del compositore risultanti. Composer gestisce qualsiasi altra cosa in modo che non ci siano altri elementi in Git.
Preparare l’archivio di monorepo
L’archivio monorepo inizia con gli stessi passaggi.
mkdir gra-monorepo
cd gra-monorepo
composer create-project --repository-url=https://repo.magento.com/ magento/project-enterprise-edition .
Installa Adobe Commerce con bin/magento setup:install, esegui commit e push.
git init
git remote add origin git@github.com:AntonEvers/gra-monorepo.git
git add composer.json composer.lock app/etc/config.php
git commit -m 'initialize monorepo GRA development repository'
git push -u origin main
Prepararsi per lo sviluppo di monorepo
Per lo sviluppo di monorepo, apporta le seguenti modifiche al file compositore.json:
- Modifica il nome e la descrizione del pacchetto in modo che sia chiaro che si tratta del pacchetto monorepo.
- Elimina l’attributo version da compositore.json, perché la versione viene gestita utilizzando i tag Git per questo archivio.
- Sostituisci la sezione require con un metapacchetto creato in un secondo momento.
- Modifica la stabilità minima in dev.
- Aggiungere un archivio di tipo percorso che punti a
packages/*/*per ospitare pacchetti monorepo, inclusi gli alias di ramo per ogni pacchetto contenuto - Aggiungi un alias di ramo per il progetto stesso
La seguente differenza Git mostra la differenza tra un’installazione pulita di Adobe Commerce e le modifiche sopra menzionate:
@@ -1,6 +1,6 @@
{
- "name": "magento/project-enterprise-edition",
- "description": "eCommerce Platform for Growth (Enterprise Edition)",
+ "name": "antonevers/gra-monorepo",
+ "description": "Monorepo repository for Global Reference Architecture development",
"type": "project",
"license": [
"proprietary"
@@ -15,11 +15,8 @@
"preferred-install": "dist",
"sort-packages": true
},
- "version": "2.4.7-p3",
"require": {
- "magento/product-enterprise-edition": "2.4.7-p3",
- "magento/composer-dependency-version-audit-plugin": "~0.1",
- "magento/composer-root-update-plugin": "^2.0.4"
+ "antonevers/gra-meta-brand-x": "self.version"
},
"autoload": {
"exclude-from-classmap": [
@@ -69,16 +66,33 @@
"Magento\\Tools\\Sanity\\": "dev/build/publication/sanity/Magento/Tools/Sanity/"
}
},
- "minimum-stability": "stable",
+ "minimum-stability": "dev",
"prefer-stable": true,
"repositories": [
{
+ "type": "path",
+ "url": "packages/*/*",
+ "options": {
+ "versions": {
+ "antonevers/gra-meta-brand-x": "1.4.x-dev",
+ "antonevers/gra-meta-foundation": "1.4.x-dev",
+ "antonevers/gra-component-foundation": "1.4.x-dev",
+ "antonevers/module-gra": "1.4.x-dev",
+ "antonevers/module-3rdparty": "1.4.x-dev",
+ "antonevers/module-local": "1.4.x-dev"
+ }
+ }
+ },
+ {
"type": "composer",
"url": "https://repo.magento.com/"
}
],
"extra": {
- "magento-force": "override"
+ "magento-force": "override",
+ "branch-alias": {
+ "dev-main": "1.4.x-dev"
+ }
}
}
Utilizzare i metapacchetti
Scarica il codice di esempio da AntonEvers/gra-meta-foundation su GitHub per ottenere i metapackages e i moduli di esempio utilizzati in questo esempio.
I metapacchetti del compositore raggruppano più pacchetti del compositore in un unico pacchetto. Quando un metapackage è richiesto, tutti i pacchetti che esso bundle sono installati automaticamente attraverso la sezione Composer require del metapackage.
Per questo esempio, sono disponibili due metapackages:
- antonevers/gra-meta-brand-x: metapacchetto che contiene tutto ciò che costituisce "Brand X"
- antonevers/gra-meta-foundation: metapackage contenente tutto ciò che è sempre installato in qualsiasi marchio
Il metapacchetto del marchio richiede il metapacchetto di base. Quando è richiesto il metapacchetto del brand, è automaticamente richiesto anche il metapacchetto di base. Consulta i due file compositore.json dei metapackages per vedere come si relazionano:
antonevers/gra-meta-brand-x:
{
"name": "antonevers/gra-meta-brand-x",
"type": "metapackage",
"license": [
"OSL-3.0",
"AFL-3.0"
],
"require": {
"antonevers/gra-meta-foundation": "^1.4",
"antonevers/module-local": "^1.4"
}
}
antonevers/gra-meta-foundation:
{
"name": "antonevers/gra-meta-foundation",
"type": "metapackage",
"license": [
"OSL-3.0",
"AFL-3.0"
],
"require": {
"antonevers/gra-component-foundation": "^1.4",
"antonevers/module-gra": "^1.4",
"antonevers/module-3rdparty": "^1.4",
"magento/composer-dependency-version-audit-plugin": "~0.1",
"magento/composer-root-update-plugin": "^2.0.4",
"magento/product-enterprise-edition": "2.4.7-p3"
}
}
I metapacchetti sono un buon modo per organizzare il codice che appartiene tra loro. Utilizza i metapacchetti per definire gruppi di pacchetti regionali, globali, specifici per il brand o qualsiasi gruppo utile per te. Se gestisci più installazioni di Adobe Commerce, i matapacchetti rappresentano un modo sicuro e versatile di definire il contesto in cui un pacchetto è previsto.
Metapackages presenti nel monorepo all'interno della directory packages. In questo caso, viene eseguito il mirroring della struttura di directory di vendor:
.
├── packages/
│ └── antonevers
│ ├── gra-meta-brand-x
│ │ └── composer.json
│ └── gra-meta-foundation
│ └── composer.json
├── composer.json
└── composer.lock
Aggiungere e sviluppare moduli
I moduli nel monorepo esistono nella directory packages. In questo modo Composer può trovarli attraverso l’archivio del tipo di percorso.
Scarica il codice di esempio da AntonEvers/gra-meta-foundation su GitHub per ottenere i metapackages e i moduli di esempio utilizzati in questo esempio.
.
├── packages/
│ └── antonevers
│ ├── gra-meta-brand-x
│ ├── gra-meta-foundation
│ ├── module-3rdparty
│ ├── module-gra
│ └── module-local
├── composer.json
└── composer.lock
Se necessario, nella directory packages possono essere presenti più spazi dei nomi.
Lo sviluppo avviene nella directory dei pacchetti. I collegamenti simbolici ai pacchetti all'interno della directory packages vengono creati nella directory vendor una volta eseguito composer update. In questo modo, il codice diventa parte dell’installazione di Adobe Commerce.
Eseguire bin/magento module:enable --all o solo per moduli specifici per abilitare i moduli aggiunti.
A questo punto è necessario disporre di un’installazione di Adobe Commerce funzionante con i tre moduli di esempio installati e funzionanti. Puoi verificare se i moduli sono installati e funzionano eseguendo i comandi:
bin/magento test:gra
bin/magento test:3rdparty
bin/magento test:local
Creazione automatizzata dei pacchetti
Sono disponibili diverse opzioni per la creazione automatica dei pacchetti. Alcune opzioni sono:
- Packagist privato
- Semplifica Generatore Monorepo
- Creare una soluzione personalizzata
Private Packagist automatizza il riconoscimento dei pacchetti in Git monorepo e li espone tramite Composer. È compatibile con Adobe Commerce, veloce, a bassa manutenzione e soggetto a errori, ed è per questo che questa guida si concentra sull’opzione Private Packagist.
Non rientra nell'ambito di questa guida spiegare come impostare l'elenco dei package privati. Vedere i documenti.
Esiste la possibilità di trasformare un pacchetto in un monorepo dopo aver configurato la sincronizzazione dell’organizzazione e gli archivi Git vengono sincronizzati automaticamente in Private Packagist.
Per prima cosa, vai alla scheda dei pacchetti e trova il monorepo:
Fai clic sul pacchetto monorepo e fai clic su "Modifica" nella schermata dei dettagli, che ti porta alla seguente pagina:
Sotto il primo campo di input è presente un collegamento che indica: Creare un archivio con più pacchetti. Fai clic su questo collegamento.
Definisci la posizione in cui trovare i pacchetti del compositore all’interno del monorepo. Nell'esempio, la posizione è packages/**/composer.json. Modifica la posizione in modo da limitare o ampliare la ricerca dei pacchetti da estrarre da parte di Private Packagist.
La scheda dei pacchetti mostra tutti i pacchetti trovati dopo il salvataggio e il monorepo stesso non sarà più visibile come pacchetto Compositore:
Viene creata una versione in Composer per ogni pacchetto all’interno del monorepo, per ogni tag o ramo creato sul monorepo in Git.
Installare i pacchetti nell’ambiente di produzione
Seguire le istruzioni di Private Packagist per aggiungere Private Packagist come repository del compositore. Private Packagist può e deve essere utilizzato come mirror per tutti gli archivi Composer e Git, incluso packagist.org. In questo modo, le credenziali non devono essere condivise con gli sviluppatori e hai il controllo completo su ogni pacchetto. Questo esempio non segue questa best practice in quanto esporrebbe pubblicamente la base di codice di Adobe Commerce.
Scarica GRA Monorepo Brand X da GitHub per visualizzare un esempio di un negozio di produzione.
Nell'archivio di produzione non è presente alcuna directory packages e tutti i pacchetti vengono installati tramite Composer. L’unico pacchetto richiesto è:
"require": {
"antonevers/gra-meta-brand-x": "^1.0"
},
Eppure, tutto Adobe Commerce e l'intero GRA è installato attraverso i requisiti di questo metapackage.
Controllo delle versioni
Tutti i pacchetti del monorepo ricevono la stessa versione del monorepo stesso. Consideralo come pubblicazione di nuove versioni dell’intera applicazione. In produzione, tuttavia, è possibile installare un mix di pacchetti da diverse versioni monorepo.
Ambienti effimeri
Se si utilizzano ambienti effimeri o si prevede di utilizzarli, il monorepo è una scelta eccellente. Ogni versione e ramo del monorepo contiene tutti i file di moduli personalizzati, di terze parti e di Adobe Commerce. Con un’installazione completa in ogni ramo, è possibile eseguire ogni tipo di test, compresi i test funzionali. Con altre configurazioni GRA, come i pacchetti separati o i pacchetti in blocco GRA, è innanzitutto necessario creare un ambiente Adobe Commerce funzionante prima di poter eseguire i test funzionali. Dal punto di vista di DevOps, monorepo lo rende molto più semplice.
Esempi di codice
Gli esempi di codice di questo articolo sono stati combinati in un set di archivi Git, che puoi utilizzare per riprodurre con la prova del concetto.
- Esempio di archivio monorepo: https://github.com/AntonEvers/gra-monorepo
- Un esempio di archivio di produzione: https://github.com/AntonEvers/gra-monorepo-brand-x