Was ist die bevorzugte Struktur eines Magento 2-Projekts unter VCS?

15

Wenn ich ein neues M2-Projekt starte, muss ich zuerst den Core über Composer installieren:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition

Ich kann jetzt meine benutzerdefinierten Module und Themen unter schreiben app/code. Ich würde dann meinen composer.*und den gesamten app/codeOrdner zu meinem VCS hinzufügen . Soweit ist alles in Ordnung.

Angenommen, ich möchte jetzt einige Build-Tools für mein Projekt verwenden, beispielsweise Grunt oder Gulp.

Wenn ich meine eigene festschreibe Gruntfile.js, wird diese durch das magento/magento2-basePaket überschrieben , wenn ich composer installnach dem Klonen des Repos starte.
Wenn ich mein festschreibe gulpfile.js, kann ich meine Abhängigkeiten in a nicht wirklich definieren package.json, da es auch von überschrieben würde magento/magento2-base.
Wenn ich mich für das Grunt-Setup von Magento entscheide und es anpassen möchte, indem ich die Dateien unter /dev/tools/grunt(z. B. themes.js) bearbeite , kann ich das nicht, da meine Änderungen von überschrieben würden magento/magento2-base.

Meines Wissens nach können Sie in Ihrem Dokumentenstamm nicht wirklich viel tun. Es gibt natürlich viele Lösungen für dieses Problem:

Ich könnte git checkout -direkt nach der Installation eine ausführen , um meine eigenen Dateien zurückzusetzen
Ich konnte meine Build - Dateien in einem speziellen Ordner speichern /buildzum Beispiel
Ich könnte ein anderes Build-Tool wie Phing, Ant oder Rake verwenden (meine Frontend-Entwickler wären allerdings nicht so glücklich)
Ich könnte magento/magento2-basemit einem benutzerdefinierten Paket ersetzen , das eine benutzerdefinierte Zuordnung für Kerndateien hat (nicht wirklich optimal, aber hey, es ist eine Option)

Ich persönlich mag all diese Optionen nicht, daher würde ich gerne wissen, ob es einen bevorzugten oder besseren Weg gibt, um das zu erreichen, was ich versuche.

Hat jemand das gleiche Problem? Wie hast du das gelöst? Wie strukturieren Sie Ihr Projekt unter VCS?

AKTUALISIEREN

Ein zusätzlicher Punkt im Zusammenhang mit der Projekteinrichtung. In meinen Experimenten habe ich festgestellt, dass der Magento Composer Installer ein Flag zum Überschreiben von Dateien hat:

"extra": {
    "magento-force": "override"
}

Es wird intern als boolescher Wert behandelt, wenn ich mich nicht irre. Deshalb habe ich versucht, ihn so einzustellen, dass das falseÜberschreiben übersprungen wird. Beim Ausführen composer installschlägt meine Installation fehl, da die Datei (en) bereits vorhanden sind. Grundsätzlich kann ich Magento nicht installieren, wenn ich meine Dateien nicht überschreiben lasse.

Was ist dann der Zweck dieser Flagge? Soll ich nur eine Überprüfung für mich durchführen? Um ehrlich zu sein, macht es für mich wenig Sinn, aber vielleicht kann jemand etwas Licht in das Thema bringen.

— fmrng
quelle

Ich bin gespannt, was andere als Antwort posten. Idealerweise möchten wir Magento Core aus unserem Hauptrepertoire heraushalten und dies auf die von uns erstellte Vorlage und die von uns hinzugefügten oder korrigierten benutzerdefinierten Plugins beschränken. Anschließend verweisen wir zum Erstellungszeitpunkt auf den Kern + unseres Projekt-Repositorys und erstellen ein Anwendungsartefakt aus den Repositorys. Dies ist die Methode, die ich in letzter Zeit für M1 verwendet habe, und ich frage mich, ob die offizielle Empfehlung von Magento lautet, etwas Ähnliches mit M2 zu tun, da Composer jetzt vollständig unterstützt wird.

— Bryan 'BJ' Hoffpauir Jr.

In neueren Versionen M2, die Gruntfile.js, gulpfile.jsund package.jsonist Problem gelöst. Das Problem adressiert in dieser Frage ist nach wie vor für neuere Magento 2 Versionen , wenn Sie ändern müssen themes.js, index.phpoder .htaccesszum Beispiel.

— 7.

4

Kurzfristig versuchen wir, Dateien zu trennen, die angepasst werden müssen. Wenn beispielsweise die Datei index.php geändert werden muss, sollten Sie herausfinden, wie Sie die Standarddatei, die Magento enthält, von der Notwendigkeit lokaler Anpassungen trennen können. Sobald dies erreicht ist, ist es möglich, einen "einen wahren .gitignore für alle Projekte zu verwenden". Das heißt, es ist einfach, Git das gesamte Projektverzeichnis mit .gitignore von allem zuzuweisen, was "composer install" für Sie abruft (und alles, was "composer update" bei der Installation eines Patches oder Upgrades ersetzt).

Langfristig ist das Ziel, .gitignore so weit wie möglich zu verkürzen. ZB mehr in Module unter dem "Vendor" -Verzeichnis.

Dann

Für alles, was Sie nicht projektübergreifend teilen möchten, lassen Sie es unter "App / Code" und "Festschreiben" im Hauptprojektrepo.
Alles, was lokal entwickelt wurde, möchten Sie einfacher projektübergreifend teilen, in ein separates GIT-Repo einfügen und über Composer installieren, sodass es unter "Anbieter" landet. (Könnte ein lokales Komponisten-Repo sein oder direkt von GIT installiert werden.)

Auf diese Weise können Sie immer noch den gesamten Projektbaum von oben nach unten festschreiben und die Dateien composer.json und composer.lock erfassen (das Festschreiben von nur App / Code funktioniert nicht). Der .gitignore schließt das Herstellerverzeichnis und andere nicht gewünschte Dateien aus.

Dies gibt Ihnen das Beste aus beiden Welten, die in der anderen Diskussion erwähnt wurden. Der aktuelle Schmerz ist die Länge und Komplexität der .gitignore-Datei, und die Patch-Installation löscht derzeit einige lokale Anpassungen (z. B. in index.php). Kurzfristige Problemumgehung: Entfernen Sie index.php aus .gitignore. Wenn Sie einen Patch installieren, überprüfen Sie, welche Änderungen Sie verloren haben (git diff), und wenden Sie sie manuell erneut an.

— Alan Kent
quelle

OK, Sie werden in naher Zukunft einige Dinge dort ändern, schön! Ich frage mich, ob diese "magento-force": "override"Flagge irgendwie nützlich sein könnte. Im Moment tut es nicht genau das, was ich erwarten würde. Falls Sie Ihre index.phpoder andere "Kern" -Dateien bearbeitet / erweitert haben , können Sie Magento einfach anweisen, Ihre Änderungen nicht zu überschreiben. Macht es irgendeinen Sinn?

— 29.

3

Es gibt eine einfache Lösung für Ihr Überschreibungsproblem: Ändern Sie keine Kerndateien;) Magento basiert darauf, den Code zu erweitern und nicht zu ändern.

Als Erstes sollten Sie nicht Ihren gesamten App- / Code-Ordner in einem vcs-Repository ablegen. Jede Magento-Komponente (Modul, Thema usw.) sollte selbst ein Repository sein.

Wenn Sie das Frontend ändern / erweitern möchten, sollten Sie ein neues Thema erstellen und dieses Thema als Ihr Hauptprojekt behandeln, nicht die gesamte Magento2-Instanz.

Um Ihr Design in Ihrem Projekt zu installieren, können Sie es einfach über Composer direkt aus Ihrem vcs-Repository herunterladen

— David Verholen
quelle

Nun, der app/codeOrdner ist speziell dazu da, Magento anzupassen. Ich verstehe das aktuelle M2 so, dass es das app/codeersetzt, was app/code/locales in M1 gab, und Community-Module können über Composer unter installiert werden vendor. Wir haben einige Projekte mit einer GROSSEN Anzahl von Modulen und auch mehrere Themen. Was Sie vorschlagen, wäre unmöglich zu verwalten.

— 27.

Hey, so verwalten wir Projekte mit> 100 Komponenten. Der Schlüssel ist, die Module klein zu halten und die Composer-Abhängigkeiten zwischen den Modulen zu verwalten. Sie können das Magento-Projekt-Repository für Ihre eigenen Bedürfnisse klonen und alle Ihre Komponenten zu Ihrem Projekt hinzufügen

— David Verholen

Wenn Sie mit Ihrem aktuellen Setup zufrieden sind, ist das in Ordnung. Ehrlich gesagt finde ich es ziemlich umständlich. Es bedeutet, dass Sie mehr als 100 Git-Repositorys haben und jedes Mal, wenn Sie etwas ändern, ein bestimmtes Projekt öffnen, Ihre Änderungen festschreiben und ausführen müssen composer update. Wo legen Sie Ihr composer.lockdann fest? Wenn mehr als 10 Entwickler an demselben Projekt arbeiten, kann es sehr chaotisch werden. Natürlich haben wir viele allgemeine Module (und sogar Themes), die wir über Composer installieren, aber aus Gründen der Übersichtlichkeit sollte projektspezifischer Code unter demselben Repo versioniert werden.

— 27.

Ich sage nicht, dass du es falsch machst, ich denke, es ist ein bisschen zu kompliziert für meinen Geschmack. Wie inspizieren Sie aus Interesse Ihre Repo-Historie mit einem solchen Setup? Wie können Sie Funktionen wie git blameoder verwenden, git logwenn der Code in mehrere Komponenten verteilt ist? Führen Sie Integrationstests durch, um sicherzustellen, dass alles einwandfrei funktioniert?

— 27.

Wir hatten diese Diskussion letztes Jahr intern und die Bereitstellung wurde ziemlich einfach, da wir beschlossen haben, 1repo = 1module zu machen. Der Punkt ist, dass Sie kein Composer-Update für eine kleine Änderung vornehmen würden. Entwickler arbeiten in Entwicklungsumgebungen und ändern dort direkt Dateien. Wenn sie fertig sind, können sie es als Alpha, Beta oder Release Candidate markieren. Auf diese Weise können mehrere Entwickler gleichzeitig an vielen Projekten arbeiten. Wenn Sie das nächste Mal ein Composer-Update vornehmen, werden alle Änderungen übernommen. Es gibt großartige Tools zum Organisieren Ihrer VCS- und Composer-Pakete. Hunderte von Repositorys sollten kein Problem sein

— David Verholen

2

Es sieht so aus, als hätte ich eine bessere Lösung für das gefunden, was ich erreichen wollte. In composer.jsonkönnen Sie festlegen, welche Dateien vom Magento Composer-Installationsprogramm ignoriert werden sollen. Wenn ich nicht möchte, dass mein Gruntfile.jsName überschrieben wird, kann ich ihn einfach mit der folgenden Konfiguration angeben:

"extra": {
    "magento-deploy-ignore": {
        "magento/magento2-base": [
            "/Gruntfile.js",
            "/package.json"
        ]
    }
}

Ich bin jetzt in der Lage, die Standardinstallation an meine Bedürfnisse anzupassen.

— fmrng
quelle

Diese Lösung scheint nicht "upgrade safe" zu sein. Wenn Magento Änderungen an diesen Dateien vornimmt, die Sie ignorieren, werden Sie diese Dateien nicht kennen oder vergessen. Sie verwenden eine eigene Version, die diese neuen Änderungen niemals enthält. Bitte überprüfen Sie meine Antwort auf meinen Vorschlag.

— 7.

2

Leider funktioniert die akzeptierte Antwort, obwohl sie ursprünglich dazu gedacht war, das gewünschte Ziel zu erreichen, nur zum Ausschließen von Dateien und Verzeichnissen, die sich im Stammverzeichnis befinden, denn wenn wir eine Datei ausschließen möchten, die sich in einem Unterverzeichnis befindet (z. B. dev/tools/grunt/configs/themes.jserforderlich, wenn wir ein hinzufügen) Wenn Sie ein neues Thema erstellen und Magento Grunt-Tasks verwenden möchten, blockiert es in der Konfiguration "magento-deploy-ignore" die Bereitstellung aller übergeordneten Verzeichnisse (d. h. dev und aller seiner Unterverzeichnisse).

Dies liegt daran, dass die Methode, die "magento-deploy-ignore" ( \MagentoHackathon\Composer\Magento\Deploystrategy\DeploystrategyAbstract::isDestinationIgnored) verwendet strpos, um den Zielpfad mit der Liste der ausgeschlossenen Pfade abzugleichen , so dass jeder übergeordnete Pfad immer true zurückgibt .

— Gennaro Vietri
quelle

Ich weiß, ich konnte das in meinen Tests sehen, aber da wir einen anderen Build-Workflow verwenden, funktioniert es gut für uns atm. Könnten Sie eine bessere Option finden?

— 22.

Wir haben während der Erstellungsphase unserer Pipeline mit dem Auschecken der Dateien begonnen und dann die Verwendung aller integrierten Grunt-Tasks eingestellt, sodass dies kein Problem darstellt.

— Gennaro Vietri

Übrigens, wir haben mit der Evaluierung von fork magento-composer-installer begonnen, um das Verhalten von "magento-deploy-ignore" zu verbessern. Sollte das Problem erneut auftreten, könnten wir diesen Weg einschlagen

— Gennaro Vietri,

0

Patches verwenden

Was ich benutze, ist das Erstellen und Anwenden von Patches. Wenn wir etwas ändern dev/tools/grunt/configs/themes.jsmüssen index.phpoder .htaccessdie Änderungen auf eine temporäre Kopie der Datei anwenden und daraus einen Patch erstellen (erst ein build/Verzeichnis erstellen ):

$ cp dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/themes.js.tmp
  # Now Make changes in .tmp file
$ diff -u3 dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/themes.js.tmp | sed 's/\.tmp//' > build/themes.patch
$ mv dev/tools/grunt/configs/themes.js.tmp dev/tools/grunt/configs/themes.js

Dann können wir diesen Patch automatisch anwenden lassen, wenn wir ihn ausführen composer installoder updateindem wir dem scriptsAbschnitt Ihrer composer.jsonDatei die folgenden Befehle hinzufügen :

{
    "scripts": {
        "post-install-cmd": "patch -i build/themes.patch dev/tools/grunt/configs/themes.js",
        "post-update-cmd": "patch -i build/themes.patch dev/tools/grunt/configs/themes.js"
    }
}

(Sie können den obigen patch ...Befehl auch in ein Bash-Skript einfügen. Nehmen wir an, Sie build/themes_patch.shrufen das Skript in Composer auf, damit es wiederverwendbar oder manuell ausführbar ist.)

Upgrade sicher! : D

Diese Lösung ist upgrade-sicher! Sie ändern Core-Dateien nicht direkt, ohne die Originaldatei zu beachten. Sie wenden einen Patch auf die ursprüngliche Magento2-Datei an. Wenn sich diese Datei aufgrund eines Upgrades ändert, schlägt der Patch fehl und Sie müssen sich die neuen Änderungen genauer ansehen und einen neuen Patch erstellen.

— 7ochem
quelle