Magento 2 als Composer Dev Voraussetzung für Erweiterungen

Wäre es beim Schreiben einer Erweiterung sinnvoll magento/project-community-edition, den require-devAbschnitt von composer.json zu erweitern?

Die Idee dahinter ist, dass nur composer installeine vollständige Magento-Installation für die Entwicklung oder CI hochgefahren werden muss.

Um die Datenbank einzurichten, würde ich ein Skript nach der Installation mit hinzufügen bin/magento setup:install.

Um die Testtools verwenden zu können, müssen Sie die Abschnitte autoload-devund require-devvon kopieren, magento/project-community-editionda diese nur aus dem Stammverzeichnis und nicht aus den Anforderungen verwendet werden.

Ein Nachteil, den ich sehe, ist, dass Sie die erforderliche Version ändern müssen, um auf mehr als zwei verschiedenen Versionen zu testen (zwei, weil Sie einen Bereich angeben und einmal installieren können --prefer-lowest), aber das ist relativ einfach zu umgehen.

Sonst noch etwas, das ich beachten muss?

Die Antwort hängt von Ihren CI-Anforderungen ab.

Für Unit-Tests prüfe ich derzeit den Ansatz, nur die tatsächlichen Magento-Module, die ich als direkte Abhängigkeit habe, in den Abschnitt "Erforderlich" aufzunehmen (dass ich sowieso fast alle Module auf diese Weise erhalte, ist für Magento zu sortieren):

"require": {
  "magento/module-backend": "~100.0.2",
  "magento/module-sales": "~100.0.2"
}

Dies funktioniert gut für eine meiner Erweiterungen, siehe Travis hier , stößt jedoch auf ein interessantes Problem bei einer anderen Erweiterung, bei der Magento eine Schnittstelle für ein Modell automatisch generieren sollte - Details hier.

Wenn Sie über Unit-Tests hinausblicken, ist es meiner Meinung nach sinnvoll, eine vorgefertigte Magento-Umgebung zu haben, in der Sie die Erweiterung installieren, anstatt bei jedem Build ein Installationsskript für die Magento-Umgebung auszuführen.

Sieht vernünftig aus. 2 Punkte zu beachten:

1. Die Installation über den Composer dauert einige Zeit
2. Wenn Sie eine Reihe von Modulen haben, ist es ziemlich unangenehm, Installationsvorgänge in CI mit Skripten zu unterstützen / durchzuführen, die für jedes Modul eindeutig sind. Wenn Sie hier etwas ändern müssen, müssen Sie alle vorhandenen Erweiterungen ändern.

Eine Möglichkeit, dies zu vermeiden, besteht darin, alles, was mit dem Build-on-CI zu tun hat, in einem separaten Repository zu speichern und als Unterrepositorys in Module aufzunehmen.

^{Gepostet im Auftrag von Peter Samoilov von foreWorks, da er nicht bei StackExchange ist. :) :)}

Es ist sinnvoll, nur die Magento-Module einzuschließen, die Ihr Modul benötigt:

• Es ist für jeden, der es installiert, klar, worauf es ankommt. Die gesamte Community-Edition ist zu umfangreich.
• Sie möchten es wahrscheinlich hauptsächlich als Unit-Test (und einige Integrationstests) testen, sodass kein funktionierender Webshop erforderlich ist.
• Die Funktionstests können in Ihrem Haupt-Webshop-Repository erstellt werden, da es dort sinnvoller ist, ein Frontend zu verwenden, und auch vom gesamten Framework als miteinander verbundene Dinge abhängen.

Grundsätzlich hängt Ihr Modul selbst nicht von der gesamten Community-Edition ab, sondern nur von einem Teil davon. Auf diese Weise können Sie es weiterhin testen, aber auch die Abhängigkeiten klarstellen.

auch nicht sicher. Mein erster Ansatz wird darin bestehen, magento2 von einem Docker-Image zu installieren, um alle Tests auszuführen.

Dies gibt Ihnen in relativ kurzer Zeit eine laufende Testumgebung, aber Sie müssen eine Build-spezifischere Konfiguration erstellen, als alles über Composer zu installieren, denke ich.