DokumentationCommerceImplementierungs-Playbook

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

Last update: Mon Jul 15 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 zur Verteilung von benutzerdefiniertem Code verwenden möchten, unter Berücksichtigung der Versionsverwaltung, der Code-Komplexität und der Abhängigkeitsverwaltung.

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ützten Versionen von:

  • Adobe Commerce auf Cloud-Infrastruktur
  • Adobe Commerce vor Ort

Sie umfasst sowohl die globale Referenzarchitektur (GRA) als auch Installationen mit einzelnen Instanzen.

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.

Verwendung von Git oder Composer

hauptsächlich über Git verwalteter Code
Code, der hauptsächlich über Composer verwaltet wird
Verwendung für eine Einzelinstanz
  • Standardansatz für die Verwaltung von Code für eine Einzelinstanz-Einrichtung
  • Wenn die Codebasis in Zukunft nicht Teil einer Markenübergreifenden Analyse sein wird
  • Wenn alle Marken auf einer einzigen Instanz als Websites ausgeführt werden
  • Wenn die Codebasis in Zukunft Teil eines Multi-Instanz-Setups werden kann oder wird
Verwendung für eine Einrichtung mit mehreren Instanzen
  • Wenn fast alle Module verknüpft sind (nicht empfohlen)
  • Wenn der Code von einem Team verwaltet wird, das nicht mit Composer vertraut ist
  • Standardansatz für die Verwaltung von Code für eine Einrichtung mit mehreren Instanzen
  • Wenn Adobe die Codebasis verwaltet oder das Wartungsteam mit Composer vertraut ist

Funktionsmatrix

Funktion
Git
Verfasser
Hauptcode-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 Verzeichnis app/ .
Die Entwicklung erfolgt im Verzeichnis vendor/ .
Verwaltung von Core-Upgrades
Adobe Commerce Core wird mit Composer installiert und aktualisiert. Das Ergebnis wird in Git übernommen
Adobe Commerce Core wird mithilfe von Composer installiert und aktualisiert. Das Ergebnis wird in Git übernommen
Verwaltung von Drittanbietermodulen
Drittanbietermodule 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 Verzeichnis vendor/ installiert.
Versionen
Die Freigabe ist durch die Befehle git merge und git pull oder git checkout gekennzeichnet
Die Freigabe ist durch die Befehle composer update und git pull oder git checkout gekennzeichnet
Anzahl der Git-Repositorys
Wenig
Viele
Entwicklungskomplexität
Einfach
Komplex
Komplexität der Pull-Anforderungen
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
Symbol Nein
Ja-Symbol
Flexibilität bei der GRA-Zusammensetzung
Symbol Nein
Ja-Symbol
Modulabhängigkeitsverwaltung
Ja-Symbol Nur durch module.xml, eingeschränkte Funktionalität
Ja-Symbol Vollständige Abhängigkeitsverwaltung durch composer.json
Modulversionierung
Ja-Symbol Sie können eine Version definieren, eine bestimmte Version kann jedoch nicht installiert werden
Ja-Symbol Unterstützung der Vollversion
Benötigte gebührenpflichtige Dienstleistungen
Git-Repository
Git-Repository, Private Packagist (± 600 EUR pro Jahr)
Bitbucket-Integration mit Jira möglich
Ja-Symbol
Ja-Symbol
Änderungen an Code, der sofort für die Installation verfügbar ist
Ja-Symbol
Ja-Symbol

Lösungen zur Vermeidung

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

    Dies führt dazu, dass alle Nachteile beider Code-Management-Stile in Ihrem Projekt kombiniert werden. Es erhöht unnötige Komplexität, Instabilität und mangelnde Flexibilität.

    Beispiel:

    • Erklären Sie dem Entwicklungsteam sowohl Git- als auch Composer-Workflows (anstelle von nur einem davon).
    • Installieren Sie inkompatible Module in "app/code", da nichts vorhanden ist, um zu verhindern, dass dies passiert.
    • Das Verschieben eines Moduls von app/code in den Composer (oder umgekehrt) ist umständlich, insbesondere bei laufender Entwicklung.

  2. satis package manager

    Private Packagisten kosten ± 600 € pro Jahr. Diese Kosten sind für die gesamte GRA kombiniert, nicht pro Marke. Versuchen Sie nicht, diese Kosten mit der kostenlosen Lösung Satis zu vermeiden. Satis aktualisiert Ihre Pakete nicht automatisch, wenn Sie Commits zu Git pushen. Auch Satis hat keine eingebaute Autorisierung. Sie müssen einen Webserver unterhalten, um Satis auszuführen. Am Ende verbringen Sie eine Vielzahl von privaten Packagisten Abonnementgebühren für Satis.

  3. Mit Git beginnen und dann zu Composer wechseln

    Entscheiden Sie sich zu Beginn Ihres Projekts für einen Code-Management-Ansatz. Der Wechsel von Git zu Composer oder umgekehrt mit laufender Entwicklung ist umständlich und könnte zu Code-Verlust und/oder Verlust des Revisionsverlaufs führen.

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