Magento2 - lokale / Staging- / Produktionsbereitstellung & Gitignore

Dies könnte eine Art von Diskussion mehr als eine Frage sein.

Ich möchte die Implementierungsrichtliniendeskriptordatei Sie mit Magento2 & folge wissen lokalen > Staging > Produktionsumgebungen

Nach einigen Versuchen haben wir entschieden, dass der beste (oder zumindest der solideste) Ansatz diese Gitignore-Datei einschließlich des Herstellerordners in Git ist.

.DS_Store
/.buildpath
/.cache
/.metadata
/.project
/.settings
atlassian*
/nbproject
/sitemap
/sitemap.xml
/.idea
/.gitattributes
/app/config_sandbox
/app/etc/config.php
/app/etc/env.php
/app/code/Magento/TestModule*
/lib/internal/flex/uploader/.actionScriptProperties
/lib/internal/flex/uploader/.flexProperties
/lib/internal/flex/uploader/.project
/lib/internal/flex/uploader/.settings
/lib/internal/flex/varien/.actionScriptProperties
/lib/internal/flex/varien/.flexLibProperties
/lib/internal/flex/varien/.project
/lib/internal/flex/varien/.settings
/node_modules
/.grunt
/pestle.phar
/pub/media/*.*
!/pub/media/.htaccess
/pub/media/catalog/*
!/pub/media/catalog/.htaccess
/pub/media/customer/*
!/pub/media/customer/.htaccess
/pub/media/downloadable/*
!/pub/media/downloadable/.htaccess
/pub/media/import/*
!/pub/media/import/.htaccess
/pub/media/theme/*
/pub/media/theme_customization/*
!/pub/media/theme_customization/.htaccess
/pub/media/wysiwyg/*
!/pub/media/wysiwyg/.htaccess
/pub/media/tmp/*
!/pub/media/tmp/.htaccess
/pub/media/captcha/*
/pub/static/***
!/pub/static/.htaccess

/var/*
!/var/.htaccess

.unison*
/sync.sh

Daher führen wir Composer nur in einer lokalen Umgebung aus: Da jede neue Erweiterung oder jedes Software-Upgrade in einer lokalen Umgebung getestet, validiert und festgeschrieben wird. Wir würden dann wahrscheinlich auch die Datei app / etc / config.php in git aufnehmen, aber diese Datei wird beim Ausführen neu geschrieben setup:upgrade, oder?

Das Einbeziehen des Anbieters bedeutet, dass die Repository-Größe größer ist als (möglicherweise) empfohlen, aber auf diese Weise führen wir beim Bereitstellen von Code einfach die folgende Sequenz aus:

bin/magento setup:upgrade
bin/magento setup:di:compile (optional)
bin/magento setup:static-content:deploy

Verwandte Informationen: http://www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2

Sehen Sie, warum wir den Befehl compile als optionales Magento 2 wählen - setup: di: compile ?

AKTUALISIEREN

Die Wahrheit ist, dass wir einige Probleme beim Bereitstellen von Codeänderungen in unseren veröffentlichten Magento 2-Projekten haben

Änderungen funktionieren in Local & Staging (in beiden Modi aktiviert: Entwickler & Produktion ... obwohl wir diese Umgebungen konzeptionell im Entwicklermodus konfigurieren), aber einige von ihnen funktionieren nicht in Produktionsumgebungen (im Produktionsmodus) usw. Ich bin mir also nicht sicher, ob wir die richtige Strategie verfolgen. Ich würde gerne sehen, wie die entsprechende Befehlssequenz lautet und welche Relevanz die Reihenfolge in diesen Befehlen hat

Tatsächlich bin ich jeden Tag weniger von der Nützlichkeit des Magento 2-Produktionsmodus überzeugt, es sei denn, Sie werden nichts am Projekt ändern. Kannst du meine Meinung ändern?

Tatsächlich bin ich jeden Tag weniger von der Nützlichkeit des Magento 2-Produktionsmodus überzeugt, es sei denn, Sie werden nichts am Projekt ändern. Kannst du meine Meinung ändern?

Ich bin mir nicht sicher, ob ich Sie richtig verstehe, aber genau dafür ist der Produktionsmodus gedacht : Produktionssysteme, in denen Sie nichts ändern (Code-weise). Bis zur nächsten Bereitstellung.

Ich finde, dass die Git-basierte Bereitstellung, die Sie verwenden, für Magento 2 aufgrund der gesamten Vorverarbeitung weniger geeignet ist als für Magento 1. Die Erstellung und Bereitstellung ist komplexer und meiner Meinung nach führt kein Weg an einem automatisierten Erstellungsprozess vorbei

Was ich empfehlen würde:

• Haben Sie wiederholbare Bereitstellungen, dh Sie sollten sicher sein, dass genau derselbe Code in der Produktion landet, die sich im Staging befand, einschließlich der generierten Dateien .

• Um dies zu erreichen, trennen Sie den Build von der Bereitstellung und führen Sie im Build-Prozess die folgenden Schritte aus:

  • composer install(Das Hinzufügen vendorzum Repository ist ebenfalls möglich. Wenn Sie dies jedoch getan haben, um zu vermeiden, dass Composer während der Bereitstellung auf dem Server ausgeführt wird, tun Sie dies lieber im Build-Schritt und behalten Sie nur composer.lockdas Repo bei.)

  • Codegenerierung (YMMV):

    bin/magento setup:di:compile
    bin/magento setup:static-content:deploy

  • ein Archiv (das Erstellen Build Artefakt ) aus dem vollen Magento Verzeichnis, ohne mediaund var, aber einschließlich vendor, pub, var/generatedund var/di. Beginnend mit magento-2.2 , var/generatedund var/dibewegt zu generated/codeundgenerated/metadata , was sie leichter zu trennen macht von den übrigen vardie für Einsätze ignoriert werden soll.

• Kopieren Sie in der Bereitstellung das Build-Artefakt auf den Zielserver, extrahieren Sie es in ein neues Verzeichnis und:

  • verknüpfen Sie persistente Verzeichnisse damit ( media,var/session , var/log, ...)
  • Wartungsmodus aktivieren
  • Dokumentstamm wechseln (normalerweise ist die Docroot ein Symlink zur letzten Version, ändern Sie sie in die neue Version)
  • Cache leeren
  • Lauf setup:upgrade
  • Wartungsmodus deaktivieren

• Dieser Bereitstellungsprozess kann problemlos mit Deployer implementiert werden , das Capistrano ähnelt , jedoch in PHP. Eine vollständige Bereitstellungslösung für Magento 2 basierend auf dem Bereitsteller finden Sie hier: https://github.com/mwr/magedeploy2 (dank netz98!) Und hier ist eine andere, die wir verwenden: https://github.com/staempfli / magento2-deploy-tool

• Das Speichern app/etc/config.phpim Repository ist gut, um aktivierte und deaktivierte Module im Auge zu behalten.

Dies ist keine schrittweise Anleitung, sondern soll Ihnen einen Überblick über eine robustere Alternative zu Ihrem aktuellen Prozess geben. Schauen Sie sich die verknüpften Tools an, um zu sehen, wie eine vollständige Lösung aussehen kann.

Warten Sie meiner Meinung nach auf Magento 2.2 oder versuchen Sie, einen ähnlichen Ansatz zu implementieren.

Magento 2.2 führt die Pipeline-Bereitstellung ein indem beispielsweise der Build-Server vom Produktionsserver getrennt wird.

Hier ist die offizielle Dokumentation: http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

Darüber hinaus verwende ich derzeit Ansible, um die automatisierte Bereitstellung mit Konfigurationsvorlagen und mehreren Umgebungseinstellungen zu verwalten.