DokumentationCommerceImplementierungs-Playbook

Best Practices für die Code-Verwaltung in Adobe Commerce

Last update: Wed Dec 18 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Erstellt für:

  • Experte
  • Entwickler

Dieses Thema soll Ihnen bei der Entscheidung helfen, ob Sie Git oder Composer verwenden möchten, um benutzerdefinierten Code zu verteilen. Dabei sind die Versionsverwaltung, die Code-Komplexität und die Abhängigkeitsverwaltung zu berücksichtigen.

NOTE
Diese Best Practices eignen sich am besten für Migrationen und Implementierungen, weniger für die Entwicklung einzelner Module.

Betroffene Produkte und Versionen

Alle unterstütztenvon:

  • Adobe Commerce auf Cloud-Infrastruktur
  • Adobe Commerce On-Premises

Definitionen

  • Globale Referenzarchitektur (GRA) Wird auch als White Label Architecture oder Common Code Base bezeichnet. Dies ist die Modulverteilungsarchitektur für ein Multi-Instanz-Setup.
  • Multi-Instanz-Setup: Derselbe Client verwendet separate Adobe Commerce-Installationen für separate Regionen oder Marken. Jede Installation verfügt sowohl über gemeinsame als auch über eindeutige Module.
  • Einzelinstanz-Setup: Es gibt nur eine Adobe Commerce-Installation. Für verschiedene Testumgebungen können mehrere Kopien des Quell-Codes vorhanden sein, es gibt jedoch nur eine Version des Produktions-Codes.

Verwendung von Git oder Composer

Code, der hauptsächlich über Git verwaltet wird
Code wird hauptsächlich durch Composer verwaltet
Verwendung für die Einrichtung einer einzelnen Instanz
  • Standardansatz für die Verwaltung von Code für eine Einzelinstanz-Einrichtung
  • Wann die Code-Basis künftig nicht mehr Teil einer Mehrmarken-GRA sein wird
  • Wenn alle Marken auf einer einzigen Instanz als Websites ausgeführt werden
  • Wann die Code-Basis Teil einer Multi-Instanz-Einrichtung werden kann oder wird
Verwendung für die Einrichtung mehrerer Instanzen
  • Wenn fast alle Module miteinander verknüpft sind (nicht empfohlen)
  • Wenn der Code von einem Team verwaltet wird, das nicht mit Composer vertraut ist
  • Standardansatz für die Code-Verwaltung bei einem Setup mit mehreren Instanzen
  • Wenn Adobe die Code-Basis verwaltet oder das Wartungsteam mit Composer vertraut ist

Funktionsmatrix

Funktion
Git
Komponist
Haupt-Code-Repository
Der gesamte Code befindet sich in einem oder mehreren Git-Repositorys
Der gesamte Code befindet sich in den Paketen in einem Composer
Repository. Jedes einzelne Composer-Paket wird durch ein Git-Repository dargestellt
Code-Speicherort
Die Entwicklung erfolgt im app/
Die Entwicklung erfolgt im vendor/
Zentrale Upgrade-Verwaltung
Adobe Commerce Core wird mit Composer installiert und aktualisiert, das Ergebnis wird in Git übertragen
Adobe Commerce Core wird mit Composer installiert und aktualisiert. Das Ergebnis wird in Git übertragen
Verwaltung von Drittanbietermodulen
Module von Drittanbietern werden in vendor/ installiert, wenn sie über den Marketplace oder packagist.org installiert werden. Andernfalls werden sie in app/ installiert
Alle Module von Drittanbietern werden im vendor/ installiert
Versionen
Die Freigabe ist durch git merge und git pull oder git checkout gekennzeichnet
Die Freigabe ist durch composer update und git pull oder git checkout gekennzeichnet
Anzahl der Git-Repositorys
wenige
Viele
Komplexität der Entwicklung
Einfach
Komplex
Komplexität der Pull-Anfrage
Einfach
Komplex
Komplexität der Code-Überprüfung
Einfach
Einfach
Komplexität der Aktualisierung der Entwicklungs-/QA-/UAT-Umgebung
Einfach
Komplex
GRA-Unterstützung
Ja-Symbol
Ja-Symbol
Module können externe Bibliotheken automatisch installieren
Kein Symbol
Ja-Symbol
Flexibilität bei der GRA-Zusammensetzung
Kein Symbol
Ja-Symbol
Abhängigkeitsverwaltung für Module
Ja-Symbol Nur durch module.xml, eingeschränkte Funktionalität
Ja-Symbol Vollständige Abhängigkeitsverwaltung über composer.json
Modulversionierung
Ja-Symbol Sie können eine Version definieren, aber Sie können eine bestimmte Version nicht installieren
Ja-Symbol Unterstützung der Vollversion
Bezahlte Services erforderlich
Git-Repository
Git-Repository, Private Packagist (± 600 € pro Jahr)
Bitbucket-Integration mit Jira möglich
Ja-Symbol
Ja-Symbol
Änderungen am Code sofort zur Installation verfügbar
Ja-Symbol
Ja-Symbol

Zu vermeidende Lösungen

  1. Kombinieren von Composer und app/code für Ihre Module

    Dadurch werden alle Nachteile beider Code-Management-Stile in Ihrem Projekt kombiniert. Sie sorgt für unnötige Komplexität, Instabilität und mangelnde Flexibilität.

    Beispiel:

    • Erklären Sie dem Entwicklungs-Team die beiden Workflows Git und Composer (anstelle von nur einem).
    • Installieren Sie inkompatible Module in app/code, da es nichts gibt, was dies verhindern könnte.
    • Das Verschieben eines Moduls von app/code zu Composer (oder umgekehrt) ist umständlich, insbesondere bei laufender Entwicklung.

  2. SATIS Package Manager

    Private Packagist kostet ± € 600 pro Jahr. Diese Kosten gelten für die gesamte GRA zusammen, nicht pro Marke. Versuchen Sie nicht, diese Kosten zu vermeiden, indem Sie die kostenlose Lösung Satis verwenden. Satis aktualisiert Ihre Pakete nicht automatisch, wenn Sie Commits an Git senden. Auch Satis hat keine integrierte Autorisierung. Sie müssen einen Webserver verwalten, um Satis ausführen zu können. Am Ende gibt man eine Vielzahl der Abonnementgebühren für Privatpakete aus, um Satis zu erhalten.

  3. Beginnen Sie mit Git und wechseln Sie dann zu Composer

    Entscheiden Sie sich zu Beginn Ihres Projekts für einen Code-Management-Ansatz. Der Wechsel von Git zu Composer oder umgekehrt ist bei fortlaufender Entwicklung umständlich und kann zu Codeverlust und/oder Verlust des Revisionsverlaufs führen.

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