Verwalten von Magento / Composer / Deployment

Ich arbeite gerne mit dem Hackathon Magento Composer-Installationsprogramm, habe jedoch Schwierigkeiten zu verstehen, wie andere es in Bezug auf einen Bereitstellungsdienst verwenden. Momentan verwende ich DeployHQ, und ja, ich kann es so einstellen, dass es Composer bereitstellt und ausführt, wenn das Repo aktualisiert wird, aber das macht für mich jetzt keinen Sinn.

Mein Haupt-Composer-Repository, das nur die JSON-Datei aller Pakete enthält, die ich in meinen Build aufnehmen möchte, wird erst aktualisiert, wenn ich der Liste ein neues Paket hinzufüge.

Wenn ich mein Design oder eine benutzerdefinierte Erweiterung aktualisiere (auf die in der JSON-Datei verwiesen wird), gibt es keinen "Haken" zum Aktualisieren meines Bereitstellungsdienstes. Also muss ich mich bei meinem Server anmelden und Composer manuell ausführen (wodurch die Site heruntergefahren wird, bis sie fertig ist).

Wie schaffen es andere? Sollte ich Composer nur lokal ausführen und den Vendor-Ordner in mein Repo aufnehmen?

Alle Antworten wäre sehr dankbar.

Ich habe in unserer Agentur eine Struktur eingerichtet, die es uns ermöglicht, mit Composer alle unsere Magento-Sites bereitzustellen. Dies mag ein wenig übertrieben für die Frage sein, die Sie gestellt haben, aber hier ist trotzdem ein grundlegender Überblick über die Struktur:

Repository-Struktur

Unten sehen Sie die Ordnerstruktur des übergeordneten Repositorys. Es enthält die Composer-JSON- und -Sperrdateien sowie andere für die Bereitstellung erforderliche Konfigurationen.

- code
   - magento
- deployment
- environmental
   - local
       - local.xml
       - robots.txt
   - staging
       - local.xml
       - robots.txt
   - production
       - local.xml
       - robots.txt
- provisioning
- public
   - index.php
- vendor
- composer.json
- composer.lock

• Alle kundenspezifischen Anpassungen werden in einem separaten Modul "Anpassungen" gespeichert, das mit Composer installiert wird
• Der Magento-Kern ist als Git-Submodul enthalten ( code/magento)
• Ein benutzerdefinierter index.phpOrdner und andere Ordner wie Medien und Fehler befinden sich in einem öffentlichen Ordner außerhalb des Magento-Stammverzeichnisses
• Umgebungsspezifische Dateien (local.xml, robots.txt usw.) werden während des Bereitstellungsprozesses mit dem Magento-Stammverzeichnis verknüpft
• Der Herstellerordner ist von Git ausgeschlossen, die Datei composer.lock ist jedoch enthalten.

Einsatz

• Wir setzen Capsitrano ein, das mehrere App-Server und -Umgebungen ermöglicht (Staging / Produktion).
• Capistrano erstellt die gesamte Codebasis auf dem Server in einem neuen Ordner und tauscht dann ganz am Ende den Webroot-Symlink aus, sodass es keine Ausfallzeiten für Ihre Website gibt.
• Capistrano wird composer installwährend des Builds ausgeführt und stellt alle Module im Magento-Submodul bereit.

Dies ist immer noch kein kontinuierliches Integrations-Setup, aber ich finde, es funktioniert gut für Magento-Sites. Sie können mir gerne eine Nachricht senden, wenn Sie weitere Ratschläge für Ihr Setup wünschen.

Eine andere Methode ist die Verwendung der Magento Hackathons Copy Deploy-Strategie, die in Ihrer composer.json-Datei ungefähr so ​​aussieht:

"extra": {
    "magento-root-dir": "./",
    "magento-deploystrategy": "copy",
    "magento-force": true
}

Mit der obigen Methode werden die installierten Dateien vom Hersteller in die eigentliche Installation kopiert, sodass sie in Git festgeschrieben und wie gewohnt bereitgestellt werden können, ohne dass eine Composer-Installation erforderlich ist.

Ich bin kein großer Fan von Abrufen aus Repositorys von Drittanbietern, wenn Sie eine Live-Bereitstellung durchführen möchten, und es ist ein gewisses Risiko, von Repositorys von Drittanbietern abhängig zu sein, es sei denn, Sie haben eine Art Proxy-Cache für Ihr Netzwerk .

Wenn Sie diesen Artikel lesen, erhalten Sie eine andere Perspektive: http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_debacle

Grundsätzlich ist NPM ausgefallen (irgendwie) und alle Build-Systeme funktionierten nicht mehr (für kritische Bereitstellungen!), Da sie direkt von NPM abhängig waren. (NPM ist ein bisschen wie Packagist für Javascript, außer dass NPM die Datei tatsächlich hostet und Packagist nur auf die Github-Repos von Modulen verweist - korrigieren Sie mich, wenn ich falsch liege.)

edit: nur red fschmenglers antwort .. dies ist eine ausarbeitung seines 1. ansatzes

Es ist wichtig zu verstehen, dass Composer kein Bereitstellungstool, sondern ein Entwicklungstool ist.

Es gibt verschiedene Ansätze zum Vorbereiten einer Bereitstellung mit allen Abhängigkeiten:

• Übernehmen Sie das Herstellerverzeichnis (oder wo immer Composer die Quellen installiert) in das Projekt-Repository
• Verwenden Sie einen Buildserver, der ausgeführt wird composer installund ein Archiv mit dem Ergebnis erstellt, das Sie wiederholbar auf verschiedenen Zielsystemen bereitstellen können
  • läuft composer installauf dem Server und wechselt dann symlinks wie von @ jharrison.au vorgeschlagen ist eine Variation von diesem

Abgesehen davon empfehle ich nicht, Composer für jedes einzelne Modul zu verwenden und nur composer.jsonund composer.lock im Projekt-Repository zu behalten . Das ist übertrieben und macht die Entwicklung unnötig kompliziert. Für Code, der für mehrere Projekte wiederverwendet wird, ist dies durchaus sinnvoll. Warum sollten Sie jedoch projektspezifischen Code in separaten Repositorys ablegen?

Meine aktuelle Projektstruktur sieht folgendermaßen aus (mit den alternativen Composer-Installationsprogrammen von AOE ):

• srcenthält alle projektspezifischen Module. Composer installiert hier auch alle anderen Magento-Module
• .modmanLinks zu, srcdamit Modman das Symlinking einfach handhaben kann
• wwwist die Webroot. Composer installiert hier den Magento-Kern

Auf diese Weise binde ich externe Module in das Repository ein. Wenn Sie dies nicht möchten, passen Sie es wie folgt an:

• srcenthält alle projektspezifischen Module. .modmanVerwenden Sie, um sie einzuschließen, damit Modman Symlinks erstelltmodman link
• .modmanist in .gitignore. Composer installiert hier Magento-Module
• wwwist die Webroot. Composer installiert hier den Magento-Kern