Beispiele für globale Referenzarchitekturen
Hier werden gängige Methoden zum Organisieren einer globalen Referenzarchitektur (GRA) -Codebasis beschrieben. Obwohl die Option separate packages bevorzugt wird, erfordern einige Situationen eine der anderen unten beschriebenen Optionen.
Definitionen
- Globale Referenzarchitektur (GRA): Wird auch als White Label Architecture oder Common Code Base bezeichnet. Dies ist die Modulverteilungsarchitektur für eine Einrichtung mit mehreren Instanzen.
- Einrichtung mehrerer Instanzen: Derselbe Client verwendet separate Adobe Commerce-Installationen für verschiedene Regionen oder Marken. Jede Installation verfügt über gemeinsame und eindeutige Module.
- Setup einer Instanz: Es gibt nur eine Adobe Commerce-Installation. Für verschiedene Testumgebungen können mehrere Kopien des Quellcodes vorhanden sein, es gibt jedoch nur eine Version des Produktionscodes.
Option 1: Separate Pakete
Informationen zum Einrichten dieser Methode finden Sie unter Best Practices für die Composer-Projektstruktur .
Die flexibelste Methode zur Verwaltung von GRA Composer-Paketen besteht in Metapaketen. Metapakete enthalten nur eine composer.json
-Datei, die andere Paketabhängigkeiten definiert. Erstellen Sie Metapakete mit Private Packagist -Repositorys.
Hauptprojekt composer.json
{
"name": "example-client/region-1",
"description": "Example Client Region 1",
"type": "project",
"require": {
"magento/product-enterprise-edition": "2.3.5",
"example-client/meta-region-1": "~1.0"
},
"minimum-stability": "dev",
"prefer-stable": true,
"repositories": [
{"type": "composer", "url": "https://repo.packagist.com/example-client/"},
{"packagist.org": false}
]
}
example-client/meta-region-1 composer.json
{
"name": "example-client/meta-region-1",
"description": "Region 1 meta package",
"type": "metapackage",
"require": {
"example-client/meta-gra": "~1.0",
"example-client/theme-frontend-region1",
"example-client/language-es-es",
"ingenico/ogone-client"
}
}
example-client/meta-gra composer.json
{
"name": "example-client/meta-gra",
"description": "GRA meta package",
"type": "metapackage",
"require": {
"geoip2/geoip2": "~2.0",
"magento-services/module-stackify-logger": "~1.1",
"example-client/sap-connector",
"example-client/service-chat",
"example-client/store-locator"
}
}
Jedes Modul, Sprachpaket, Design und jede Bibliothek verfügt über ein eigenes Git-Repository. Jedes Git-Repository synchronisiert automatisch mit dem privaten Packagist-Repository und generiert dort ein Paket, solange sich im Stammverzeichnis des Git-Repositorys eine composer.json
-Datei befindet.
Optionen 2: Massenpakete
Nachfolgend finden Sie ein Beispiel für mehrere Module in einem einzelnen Composer-Paket.
Ein Massenpaket kann nur Pakete desselben Typs enthalten. Wenn Sie beispielsweise mehrere Pakete für Adobe Commerce-Module, Designs, Sprachpakete und Bibliotheken haben, müssen Sie für jeden Typ separate Bulk-Pakete erstellen.
Die Dateistruktur im Verzeichnis "Anbieter"sollte wie im folgenden Beispiel aussehen. Prüfen Sie jedoch Ihr Projekt, um zu sehen, was in Ihrem Git-Repository enthalten sein sollte):
.
└── example-client/
└── gra/
└── src/
├── SapConnector/
│ ├── etc/
│ └── registration.php
├── ServiceChat/
│ ├── etc/
│ └── registration.php
├── StoreLocator/
│ ├── etc/
│ └── registration.php
└── composer.json
Die Datei composer.json
sollte wie folgt aussehen:
{
"name": "example-client/gra",
"description": "GRA Modules",
"require": {
"magento/magento-composer-installer": "*"
},
"type": "magento2-module",
"autoload": {
"files": [
"src/SapConnector/registration.php",
"src/ServiceChat/registration.php",
"src/StoreLocator/registration.php"
],
"psr-4": {
"ExampleClient\\SapConnector\\": "src/SapConnector",
"ExampleClient\\ServiceChat\\": "src/ServiceChat",
"ExampleClient\\StoreLocator\\": "src/StoreLocator"
}
}
}
Option 3: Git teilen
Diese Architektur verwendet vier Git-Repositorys zum Speichern von Code:
core
: Enthält die Adobe Commerce-Kerninstallation. Wird verwendet, um Adobe Commerce-Versionen zu aktualisieren.- 0: Enthält GRA-Code.
GRA
Alle GRA-Module, Sprachpakete, White Label-Designs und Bibliotheken. brand/region
: Jede Marke oder Region verfügt über ein eigenes Repository mit nur marken- oder regionsspezifischem Code.release
: Alle oben genannten Elemente werden in diesem Git-Repository zusammengeführt. Hier sind nur Zusammenführungsbefehle zulässig.
So richten Sie diese Option ein:
-
Erstellen Sie die vier Repository-Typen in Git. Erstellen Sie die Repositorys
core
undGRA
nur einmal. Erstellen Sie für jede Marke einbrand/region
- und einrelease
-Repository.Vorgeschlagene Repository-Namen:
m2-core
m2-gra
m2-region-x
/m2-brand-x
(z. B.m2-emea
/m2-adobe
)m2-release-region-x
/m2-release-brand-x
(z. B.m2-release-emea
/m2-release-adobe
)
-
Erstellen Sie ein Verzeichnis "
release/
" und führen Sie Folgendes aus, um einen freigegebenen Git-Verlauf für alle Repos zu erstellen.code language-bash git init git remote add origin git@github.com:example-client/m2-release-brand-x.git git remote add core git@github.com:example-client/m2-core.git git remote add gra git@github.com:example-client/m2-gra.git git remote add region-x git@github.com:example-client/m2-region-x.git touch .gitkeep git add .gitkeep git commit -m 'initialize repository' git push -u origin master git push core master git push gra master git push region-x master
-
Klonen Sie jedes Repository mit Ausnahme von
core
in einem anderen Verzeichnis auf Ihrem Computer.code language-bash git clone git@github.com:example-client/m2-release-brand-x.git git clone git@github.com:example-client/m2-region-x.git git clone git@github.com:example-client/m2-gra.git
-
Installieren Sie Adobe Commerce mit Composer. Entfernen Sie die Datei "
.gitignore
", fügen Sie die Remote-Adresse "core
"hinzu, fügen Sie den Code hinzu, übertragen Sie ihn und pushen Sie ihn.code language-bash composer create-project --repository-url=https://repo.magento.com/ magento/project-enterprise-edition m2-core cd m2-core git init rm .gitignore git remote add origin git@github.com:example-client/m2-core.git git fetch git checkout .gitkeep git add --all git commit -m 'install Adobe Commerce' git push
-
Erstellen Sie im Repository
GRA
die folgenden Ordner:app/code/
app/design/
app/i18n/
lib/
-
Code hinzufügen. Entfernen Sie die Datei "
.gitignore
", fügen Sie den Code hinzu und übertragen Sie ihn, fügen Sie die Remote- und Push-Benachrichtigung hinzu. -
Im Repository
brand/region
. Gehen Sie genauso vor wie imGRA
-Repository und beachten Sie, dass Dateien eindeutig sein müssen. Dieselbe Datei kann nicht sowohl in dieses Repository als auch in das RepositoryGRA
eingefügt werden. -
Wenden Sie die Zusammenführung im
release
-Repository an.code language-bash git clone git@github.com:example-client/m2-release-brand-x.git cd m2-release-brand-x git remote add core git@github.com:example-client/m2-core.git git remote add gra git@github.com:example-client/m2-gra.git git remote add region-x git@github.com:example-client/m2-region-x.git git fetch --all git merge core/master gra/master brand-a/master git push
-
Entfernen Sie die Datei "
.gitkeep
". -
Stellen Sie das
release
-Repository auf den Produktions-, Test-, QA- und Entwicklungsservern bereit. Die Aktualisierung voncore
-,GRA
- undbrand
-Code ist ebenso einfach wie die Ausführung der folgenden Befehle:code language-bash git fetch --all git merge core/master gra/master brand-a/master git push
Option 4: Monorepo (empfohlen)
Diese Strategie ahmt genau nach, wie das Magento Open Source-Git-Repository funktioniert.
Der gesamte Code wird in einem einzigen Repository entwickelt und getestet. Durch die Automatisierung werden Pakete aus diesem einzigen Repository entfernt, das mithilfe von Composer in UAT- und Produktionsumgebungen installiert werden kann.
Die monorepo -Option ermöglicht Ihnen die einfache Arbeit in einem einzelnen Repository und bietet gleichzeitig die Flexibilität, Instanzen mit Paketen zusammenzustellen.
Die Versionierung und Paketdestillation erfolgt durch Automatisierung, mithilfe von GitHub-Aktionen oder GitLab-Aktionen.
Weitere Informationen zu dieser Automatisierung finden Sie in den folgenden Ressourcen:
Strategien nicht mischen
Es ist nicht ratsam, einen kombinierten Ansatz mit Composer für GRA-Pakete und das Verzeichnis app/
für Marken- oder Regionspakete zu verwenden.
Sie erhalten nicht nur alle Vor, sondern auch alle Nachteile beider Methoden. Sie sollten das eine oder das andere auswählen (Git oder Composer), um optimal zu funktionieren.
Lösungen zur Vermeidung
-
Namenskonventionen für Module zur Angabe von GRA oder Marke
Namensmodule, die GRA oder Marke darstellen, führen zu mangelnder Flexibilität. Verwenden Sie stattdessen Composer-Metapakete, um zu bestimmen, zu welcher Gruppe ein Modul gehört. Beispielsweise enthält Package
vf/meta-gra
für Kunden-VF Verweise auf alle GRA-Pakete und kann mit dem Befehlcomposer require vf/meta-gra
installiert werden. Paketvf/meta-kipling
enthält Verweise auf alle Kipling-spezifischen Pakete und auf das Paketvf/meta-gra
. Module haben beispielsweise die Namenvf/module-sales
undvf/module-sap
. Mit dieser Namenskonvention können Sie Pakete mit geringer Auswirkung zwischen Marke und GRA-Status verschieben. -
Adobe Commerce Core-Upgrades pro Instanz
Planen Sie zentrale Adobe Commerce-Upgrades, einschließlich Patch-Upgrades, für verschiedene Marken oder Regionen so nah wie möglich an einer Stelle wie möglich. Die Unterstützung mehrerer Adobe Commerce-Versionen für gemeinsam genutzte Module führt aufgrund von Kompatibilitätsbeschränkungen zur Abspaltung von Modulen und verdoppelt den Wartungsaufwand mehr als. Verhindern Sie diesen erhöhten Aufwand, indem Sie sicherstellen, dass alle Instanzen auf derselben Adobe Commerce-Version ausgeführt werden, bevor Sie die reguläre Entwicklung fortsetzen.