Beispiele für globale Referenzarchitekturen

In diesem Thema werden gängige Methoden zur Organisation einer globale Referenzarchitektur (GRA) Codebasis. Obwohl die Variable separate Pakete empfohlen 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 Einzelinstanz: 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

Siehe Projektstruktur des Composers Best Practices für die Einrichtung dieser Methode.

Abbildung der Option für separate Pakete für die globale Referenzarchitektur

Die flexibelste Methode zur Verwaltung von GRA Composer-Paketen besteht in Metapaketen. Metapakete enthalten eine composer.json -Datei, die andere Paketabhängigkeiten definiert. Erstellen von Metapaketen 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 ein composer.json im Stammverzeichnis des Git-Repositorys.

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 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.
  • GRA: Enthält GRA-Code. 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.

Abbildung der Git-Aufspaltungsoption für die globale Referenzarchitektur

So richten Sie diese Option ein:

  1. Erstellen Sie die vier Repository-Typen in Git. Erstellen Sie die core und GRA Repositorys nur einmal. Erstellen einer brand/region und einem release Repository für jede Marke.

    Vorgeschlagene Repository-Namen:

    • m2-core
    • m2-gra
    • m2-region-x/m2-brand-x (zum Beispiel: m2-emea/m2-adobe)
    • m2-release-region-x/m2-release-brand-x (zum Beispiel: m2-release-emea/m2-release-adobe)
  2. Erstellen Sie eine 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
    
  3. Jedes Repository klonen, außer 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
    
  4. Installieren von Adobe Commerce mit Composer. Entfernen Sie die .gitignore -Datei, fügen Sie die core entfernen, den Code hinzufügen und übertragen und pushen.

    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
    
  5. Im GRA Repository erstellen Sie die folgenden Verzeichnisse:

    • app/code/
    • app/design/
    • app/i18n/
    • lib/
  6. Code hinzufügen. Entfernen Sie die .gitignore -Datei, fügen Sie den Code hinzu und übertragen Sie ihn, fügen Sie die Remote- und Push-Benachrichtigung hinzu.

  7. Im brand/region Repository. Gehen Sie wie in GRA Repository zu speichern und zu beachten, dass Dateien eindeutig sein müssen. Dieselbe Datei kann nicht sowohl in dieses Repository als auch in die GRA Repository.

  8. Im release Repository verwenden, die Zusammenführung anwenden.

    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
    
  9. Entfernen Sie die .gitkeep -Datei.

  10. Stellen Sie die release Repository auf den Produktions-, Test-, QA- und Entwicklungsservern. Upgrade core, GRA, und brand -Code ist so einfach, die folgenden Befehle auszuführen:

    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.

Abbildung der Monorepo-Option für die globale Referenzarchitektur

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.

Abbildung der Monorepo-Option für die globale Referenzarchitektur

Weitere Informationen zu dieser Automatisierung finden Sie in den folgenden Ressourcen:

TIP
Die Einrichtung eines Monorepos ist zwar fortgeschritten, bietet jedoch die größte Flexibilität bei den geringsten Gemeinkosten.

Strategien nicht mischen

Es ist nicht ratsam, einen kombinierten Ansatz mit Composer für GRA-Pakete und die app/ Verzeichnis für Marken- oder Regionspakete.

Sie bekommen nicht nur alle Vorteile aber auch Nachteile von beiden 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. Beispiel: Für Kunden-VF: package vf/meta-gra enthält Verweise auf alle GRA-Pakete und kann mithilfe der composer require vf/meta-gra Befehl. Paket vf/meta-kipling enthält Verweise auf alle Kipling-spezifischen Pakete und auf die vf/meta-gra Paket. Module werden vf/module-sales und vf/module-sap zum Beispiel. 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.

recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60