GIT- und Bereitstellungsstrategie Magento2-Projekte

92

Mit Magento 1 habe ich ein Deployment-Tool verwendet, das das GIT-Repository geladen, Befehle ausgeführt modman deploy-allund sichergestellt hat, dass das varVerzeichnis schreibbar ist. Für den habe .gitignoreich diesen benutzt, der ziemlich gut funktioniert hat.

Aber was ist mit Magento 2 ?

Welcher Gitignore funktioniert am besten, wie stellen Sie Ihr Projekt bereit und welcher Befehl sollte vor und nach der Bereitstellung ausgeführt werden? Wir freuen uns auf ein paar Einblicke aus der Community.

Die Frage bleibt noch einige Zeit offen

magento2

— Sander Mangel
quelle

Gute Frage @sander Mangel

— Amit Bera

1

Per Definition kann es keine kanonische Antwort auf diese Frage geben, daher ist sie wahrscheinlich zu weit gefasst und passt auch nicht zum Q & A-Charakter der Site. Sollte wahrscheinlich meta sein. Aber das weißt du schon. Das heißt, ich werde es erlauben, bis das Kopfgeld abläuft.

— Philwinkle

@philwinkle es könnte breit sein, aber anscheinend nicht zu breit, da bereits 3 Antworten gegeben wurden. Wie hier besprochen: meta.magento.stackexchange.com/questions/745/… Meta wird für Fragen zu MageSE verwendet, nicht für zufällige Beiträge / Fragen. Wenn du es löschen willst, kann ich dich nicht aufhalten, aber es scheint eine Menge Leute interessieren sich für die Frage und meiner Meinung nach ist es eine gültige, sei es nicht zu spezifisch.

— Sander Mangel

Zwei Dinge: Erstens ist Sander in Bezug auf Meta korrekt - es sollte nur für Fragen zur SE-Plattform in Bezug auf Magento SE verwendet werden (Hinweis: Wir haben Meta möglicherweise nicht gut genug überwacht, um diese Regel zu verstärken). Zweitens hat "eine Menge Leute, die an einer Frage interessiert sind" nichts damit zu tun, ob eine Frage kanonisch beantwortet werden kann oder nicht (und daher mit der Eignung einer Frage für das StackExchange-Format). Es ist auf jeden Fall frustrierend (ich bin selbst darauf gestoßen). Ich bin gespannt, wohin dieser Q / A-Thread führt. Vielleicht kann ein A gut genug angegeben werden, um ausschließlich "richtig" zu sein ...

— markiert den

@benmarks in diesem Fall habe ich den falschen Grund oder das falsche Thema für das Kopfgeld ausgewählt. Meine Motivation dahinter war es, denjenigen zu belohnen, der sich die Zeit genommen hat, eine vollständige Antwort darauf aufzuschreiben. Wenn dieser Thread nicht hierher gehört, kopiere ich ihn und poste ihn irgendwo online. Bitte benachrichtigen Sie mich vor dem Löschen

— Sander Mangel

56

In den folgenden Schritten wird beschrieben, wie die Umgebung für die Entwicklung benutzerdefinierter Module und nicht für die Produktion eingerichtet wird.

Projektinitialisierung

Fügen Sie repo.magento.com-Anmeldeinformationen und Github-Zugriffstoken zu auth.json im Ausgangsverzeichnis von Composer hinzu
Erstellen Sie ein Projekt mit dem folgenden Befehl:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .
Nehmen Sie dieses .gitignore und legen Sie es in Ihrem Projektstamm ab. Fast alle Core-Dateien / -Verzeichnisse sind bereits im Stammverzeichnis enthalten .gitignore. Es ist jedoch besser, auch die folgenden 2 hinzuzufügen /updateund /phpserver(fügen Sie diese 2 Zeilen einfach zu .gitignore hinzu).
Initialisieren Sie das neue Git-Repository im Projektstamm
Fügen Sie alle nicht verfolgten Dateien zu git hinzu und schreiben Sie sie fest
Starten Sie die Entwicklung Ihrer Module wie gewohnt (setzen Sie sie unter app/code/VendorName/ModuleName), jetzt haben Sie nur Ihren benutzerdefinierten Code in Ihrem Git-Repository

Magento-Installation

Stellen Sie sicher, dass alle Dateisystemberechtigungen wie im offiziellen Handbuch beschrieben festgelegt sind
Installieren Sie Magento über die Kommandozeile, zB:

${project_root}/bin/magento setup:install \ --db-host=localhost \ --db-name=magento \ --db-user=root \ --backend-frontname=admin \ --base-url=http://base.url.goes.here/ \ --language=en_US \ --timezone=America/Chicago \ --currency=USD \ --admin-lastname=Admin \ --admin-firstname=Admin \ --admin-email=admin@example.com \ --admin-user=admin \ --admin-password=123123q \ --cleanup-database \ --use-rewrites=1
Aktivieren Sie den Cron-Job für Indexer, z. B. unter Ubuntu:

echo "* * * * * php ${project_root}/bin/magento cron:run &" | crontab -u www-data -
Magento wird im defaultModus ausgeführt und alle fehlenden Inhalte werden bei der ersten Anforderung automatisch generiert. Sie müssen also keinen Compiler ausführen oder statische Inhalte bereitstellen
[optional] Wenn Sie PHP Storm verwenden, führen Sie den folgenden Befehl aus, um die XSD-Unterstützung zu aktivieren:

bin/magento dev:urn-catalog:generate .idea/misc.xml

— Alex Paliarush
quelle

Hallo Alex. Projektinitialisierung Schritt 3 - Könnten Sie es etwas erweitern? Haben Sie festgestellt, dass Sie dieses Unterverzeichnis manuell in das Stammverzeichnis kopieren müssen? (Ich frage mich, ob etwas nicht richtig funktioniert - ich hatte diesen Schritt nicht erwartet.)

— Alan Kent

Mit @AlanKent erhalten Sie derzeit alle Magento-bezogenen Dateien vendor, einschließlich magento2-base, die nur ein Grundgerüst für ein neues Projekt darstellen. Wenn Sie nicht sicher sind, warum dieser Schritt nicht so konfiguriert ist, dass er vom Komponisten automatisch ausgeführt wird, versuchen Sie es herauszufinden. Bezüglich des .gitignoreKopierens von einem anderen Repo wird bereits diskutiert, wie dieser Schritt beseitigt / vereinfacht werden kann.

— Alex Paliarush

Schritt 3 ist nicht erforderlich. Das Marshalling der Dateien / Ordner erfolgt in Schritt 2.

— Maddy

Vielen Dank, @Maddy. @AlanKent, Kopieren magento2-basein das Stammverzeichnis ist nicht mehr erforderlich (nur überprüft), scheint in letzter Zeit behoben worden zu sein. Diesen Schritt aus der Antwort entfernt.

— Alex Paliarush

1) Ich habe meinen gesamten Code in das Repo geschrieben, das bereits deinstalliert ist. Wenn ich aus diesem Repo herausgehe und nur die Einstellungen für den Admin-Pangel und die DB-Anmeldeinformationen ändere, funktioniert dann alles korrekt? 2) Da ich vergessen habe, var / und pub / folder während des Pushs auszuschließen, kann ich sie vollständig löschen, damit sie auf dem Remote-Repo gelöscht werden können. Werden sie dann wieder neu generiert? Vielen Dank.

— Lachezar Raychev

25

Für die Initialisierung und Installation folgen Sie den Schritten von Alex, seine Antwort für die meisten Schritte, nur Unterschiede, die ich empfehlen würde:

Git-Konfiguration

Speichern Sie nur die folgenden Dateien in Ihrem Git-Repository:

composer.json
composer.lock
app / etc / config.php

Verwenden Sie für Ihren projektspezifischen Code auch separate Module, die Sie über Composer einbinden. Die Verwaltung über Composer ist einfacher, da Sie eine bestimmte Version / Release sperren können, die Sie bereitstellen möchten. Dies zwingt Sie auch dazu, den gleichen Ansatz für interne und externe Module zu verwenden.

Einsatz

Während der Entwicklung aktualisieren Sie die Module in Ihrer Umgebung (dev / test) mit dem Befehl:

composer update

Dadurch wird die Datei composer.lock mit den bei dieser Installation installierten Versionen aktualisiert.

Bei Staging / Pre-Production / Production können Sie dasselbe Setup mit dem folgenden Befehl erstellen / installieren:

git pull
composer install

Dadurch werden alle Module installiert, die in dev / test verwendet werden, um sicherzustellen, dass die Tests vor dem Veröffentlichen in der Produktion mit denselben Modulversionen durchgeführt werden, mit denen sie entwickelt wurden.

Nach der Installation führen Sie die folgenden Befehle aus:

bin/magento setup:upgrade
bin/magento setup:di:compile (or setup:di:compile-multi-tenant)
bin/magento setup:static-content:deploy

Dadurch wird die Datenbank aktualisiert (Schema- und Datenaktualisierung), die DI-Konfiguration generiert und alle statischen Ansichtsdateien bereitgestellt.

— Vladimir Kerkhoff
quelle

Vielleicht ist es sinnvoll, Beispieldaten zu verwenden, anstatt Fixtures zu generieren? Geräte füllen nur die kritischsten Module und scheinen nur für Leistungstests nützlich zu sein.

— Alex Paliarush

Vielen Dank, dieses Teil wurde entfernt, da es bei der Verwendung einer Site in der Produktion nicht benötigt wird.

— Vladimir Kerkhoff

Dies folgt sehr genau dem Ansatz, den ich auch verwende. Dies funktioniert auch gut mit Magento 1 (mit einem weniger komplexen Erstellungsprozess). Lassen Sie Composer seine Aufgabe erledigen, es funktioniert meiner Erfahrung nach sehr gut für Bereitstellungen, und wir haben bei Ihnen nicht viele Nachteile außer der Komplexität der .gitignore-Strategie gesehen Folgen Sie nicht dem kleineren Footprint in Git.

— Aepod

Diese Installation sieht aus wie der Weg des Integrators. Es fügt die Repos in vendor / magento / * hinzu. In app / code / .. und anderen Verzeichnissen ist kein Code enthalten. Wie hätte ich Magento 2 Core-Verzeichnisse wie im .zip-Archiv. Ist es möglich, über den Komponisten ein Modul (anderes Git Repo) hinzuzufügen und dann automatisch in app / code / ... zu landen?

— dunkel

4

riskant, Komponist ist kein Bereitstellungstool. Wenn etwas auf Composer-Installation während der Ausführung in der Produktion fehlschlägt ...

— Claudiu Creanga

3

Re .gitignore, ab 2.2 lautet die offizielle Antwort von Magento "config.php geht in git, env.php nicht".

Wir suchen nach Composer-Plugins wie dem Mediawiki, um interne Entwickler näher an die Entwicklung von Erweiterungen und Kundenseiten heranzuführen. Noch zu erforschen, noch nicht endgültig.

Ich mochte es sehr, den Composer-Repository-Typ "Path" mit einem Pfad ../othergitrepo/app/code/*/*zum Aufnehmen von Modulen zu verwenden, aber er verwendet Symlinks, die in Entwicklungsumgebungen mit Unison oder ähnlichem nicht so gut funktionieren.

— Alan Kent
quelle

3

Wir verfolgen einen anderen Ansatz, der keinen separaten Build-Server / -Prozess umfasst . Wir entwickeln ihn lokal wie in der Produktion

Wir übergeben dann alle für die Produktion notwendigen Dateien . Anschließend stellen wir einfach die Changesets auf dem Server bereit und führen den Upgrade-Befehl aus.

Eine Version zu finden, die für die Entwicklung geeignet ist, aber auch im Produktionsmodus läuft, war der schwierige Teil und ist immer noch nicht perfekt, aber jetzt haben wir ein Rezept, das funktioniert.

Der Grund dafür ist, dass wir 100% Kontrolle darüber haben wollen, welcher Code in die Produktion geht. da magento2 eine tonne code generiert, müssen wir ihn lokal ausführen, um alle effekte zu verstehen und wie in der produktion debuggen zu können.

Mir ist bewusst, dass dies nicht das ist, was viele Leute empfehlen, aber für uns funktioniert es am besten.

Frontend-Setup-Schritte

Um diese Skripte zu arbeiten , um Ihr Geschäft setzen Produktionsbetrieb in Ihrem env.php und Einrichtung Ihres Thema in dev/tools/grunt/configs/themes.js. (Die folgenden Schritte wurden in ein anzeigbares Spielbuch geschrieben)

löschen var/cache
löschen var/view_preprocessed
löschen pub/static/*(den .htaccess nicht löschen)
löschen var/composer_home
Lauf php bin/magento cache:flush
Lauf php bin/magento setup:static-content:deploy %your_languages%
lösche alle Themes / Sprachen, die du nicht wirklich benutzt, aus pub / static / frontend
Entfernen Sie gedruckte Kopien weniger Dateien von pub/static/frontend
Lauf php bin/magento dev:source-theme:deploy --locale="%your_language%" --theme="%your_theme%" css/styles-m css/styles-l css/email css/email-inline
Optional: Wir verwenden ein Bash-Skript, um die in Schritt 9 erstellten absoluten Symlinks in relative zu ändern, sodass Grunzen von außerhalb des VM möglich ist
Lauf grunt less:your_theme

Backend / Deinstallationsschritte

löschen var/cache
löschen var/generation
löschen var/composer_home
löschen var/di
Lauf php bin/magento cache:flush
Lauf php bin/magento setup:di:compile

— greenone83
quelle

Vielen Dank für dieses @ greenone83. Dies ist der Ansatz, den ich im Grunde genommen gewählt habe, obwohl ich mein Backend als Teil des Frontends generiere. Ich verwende NIEMALS setup: di: compile, wenn ich es versaut finde! Eine Sache, die ich nicht verstehe, ist, warum Setup: Statischer Inhalt: Deployment erstellt Dateien in generiert / Code (der Speicherort hat sich von Ihrem Beitrag geändert)? Ich habe festgestellt, dass, wenn ich den gesamten generierten / Code lösche, diese Dateien bei meiner Site im Produktionsmodus automatisch erstellt werden, wenn ich mich auf der Site umschaue.

— PedroKTFC

2

Sie sollten diese Dateien auch ignorieren:
/app/etc/config.php
/app/etc/env.php
/.idea/workspace.xml // phpstorm

— mrtuvn
quelle

2

Wenn Sie die config.php ignorieren, müssen Sie die neue Erweiterung erneut aktivieren, nachdem Sie sie in eine andere Umgebung verschoben haben. Daher ist es besser, sie in Ihr Repository aufzunehmen.

— Vladimir Kerkhoff