Post Format

Shopware Deployment mit Mina

2 comments

In den letzten Monaten habe ich sehr viel mit Shopware gearbeitet. Und wenn man an einem größeren Projekt arbeitet, braucht man auch einen soliden Workflow. Besonders wenn man die Änderungen die man macht nicht nur lokal sehen will, sondern auch auf dem staging Server.

Bei kleineren Projekten kann man sich in Sublime Text mit dem SFT Plugin einfach eine config anlegen und die Daten dann über Sublime hochschieben. Bei größeren Projekten geht das gar nicht. Besonders nicht bei Shopware.

Grundsätzlich müsste man bei Shopware mehrere Verzeichnisse synchronisieren. Einmal das Templates / Themes Verzeichnis und einmal das Plugin Verzeichnis, wo die lokalen selbstgeschriebenen Plugins rein kommen. Kurze Anmerkung an dieser Stelle: Bei Shopware 4 waren die Shop Designs unter /templates/ mit Shopware 5 hat sich das geändert und man findet sie nun unter /themes/ mit einer etwas anderen Struktur.

Vorbereitung

Es ist eine Qual alle Dateien wie 1990 per FTP hochzuschieben und kostet auch einfach viel zu viel Zeit. Weil man ja auch nicht das komplette Verzeichnis hochladen und überschreiben will / kann. Deswegen gibt es kleine Helfer Programme. Deploy scripte. Ein recht bekanntes ist da Capistrano.
Ich verwende aber eine kleinere und schnellere Alternative, namens Mina.

Installation

Mina ist als Ruby Gem verfügbar und lässt sich dementsprechend sehr leicht installieren.

Danach wechselt man in das Shopware Hauptverzeichnis und führt eine Initialisierung aus. Diese erstellt einem unter config/deploy.rb die Konfiguration für das Projekt.

Konfiguration

Anschließend müssen wir den Deploy Vorgang konfigurieren. Dazu öffnet man die deploy.rb die unter config/ liegt mit dem Editor öffnen.

Vieles von der Config kann man auskommentieren, da Shopware keine Rails Anwendung ist und man so Sachen wie Bundler nicht braucht. Wichtig sind folgende Einträge:

Die meisten Sachen sind selbsterklärend. Die Domain zum staging Server, der absolute Pfad zum Web Verzeichnis, das Repository des Projekts, der Branch von dem aus Deployed werden soll und der SSH User.  Bestenfalls hinterlegt man seinen SSH Key auf dem Server, sodass man nicht immer sein Passwort eingeben muss. Das gleiche bei Bitbucket / Github etc.

Funktionsweise

Nochmal ein kurzer Ausflug in die Funktionsweise von Mina, damit wir gleich den weiteren Teil der Konfiguration auch verstehen. Mina benutzt wie schon gesehen, Git zum deployn. Man gibt einen Branch an und Mina erstellt auf dem Server ein bare repository und zieht dann die Änderungen aus dem Repository. Man hat eine bestimmte Ordnerstruktur, es gibt einmal den releases/ Order der nummerierte Unterordner hat. 1/, 2/, 3/… etc. das sind die jeweiligen Releases. Und einen Ordner der nur ein symlink ist, current/ . Dieser zeigt immer auf das aktuelle Release.

Weiterhin gibt es noch ein shared/ Verzeichnis. Dort sind release unabhängige Daten. Wie z.B. Uploads, Bilder etc.

Shared Folder bei Mina einrichten

Bei Shopware hat man mehrere Ordner die man als Shared Folders benutzen kann. Einmal das files/ Verzeichnis, welches Dateiuploads beinhaltet, media mit den Bildern und Thumbnails, logs, cache und web.  Außerdem noch die config.php wo die Datenbankdaten drin stehen. Andernfalls müsste man die config.php mit Datenbank Benutzer und Passwort im Repository haben, was nicht wirklich sicher ist.

Deploy Task

Der Deploy Task ist recht einfach:

Mina führt ein git clone aus, erstellt die symlinks für die shared folders und am Ende kommt ein Cleanup, welches alte Releases löscht. Ganz am Anfang haben wir mit keep_releases ja angegeben, wie viele Releases behalten werden sollen.

Rollback

Ein weiterer wichtiger Task ist der Rollback. Nun wir führen den Deploy aus und irgendwas läuft schief oder ist zerschossen. Dann können wir mit dem Rollback Task ein Release zurücksetzen.

Und das war’s eigentlich. Ich für meinen Teil entwickle meine Themes meistens mit gulp/grunt und bower. Das heißt, in meinem Repository sind keine Vendor Dateien und auch keine CSS Dateien, da ich less verwende.  Das Theme wäre so also zerschossen. Nun gibt es zwei Möglichkeiten:

Die erste Möglichkeit ist, dass ihr npm auf dem Server installiert habt. Dann könnt ihr einen Task machen der gulp und bower installiert oder es global auf dem Server installieren und dann einen task der einmal bower install und grunt build ausführt.

Falls ihr keine Möglichkeit habt, npm auf dem Server zu installieren, reicht ein kleines Shellscript aus, welches über scp oder rsync die css, js und die Vendor Dateien hochläd. Sind ein paar Zeilen und sparen einem viel Arbeit.

Alternativ, wenn ihr alleine an dem Projekt arbeitet, könnt ihr auch die css, js und vendor Dateien im repository commiten. Wenn man mit mehreren Arbeitet, würde ich das nicht machen, da es immer merge conflicts bei den css und js Daten gibt, da diese ja aus den less Daten generiert sind.

Server Setup

Nun ist wechseln wir wieder in das Shopware Verzeichnis und führen mina setup  von der Konsole aus, aus. Mina verbindet sich über ssh mit dem Server und legt die Verzeichnis Struktur mit current, releases, shared etc. an.

Wenn das fertig ist, können wir über  mina deploy  den ersten Deploy starten.

Nun sollte alles Funktioniert haben, aber Shopware wird noch nicht laufen. Dazu müssen wir noch einige Schritte beachten.

Finalisieren

Die Shared Ordner, media, logs, files etc. müssen über ssh auf chmod -R 775 gesetzt werden, damit Shopware diese beschreiben kann. Und wir müssen unsere config.php anpassen und die Datenbankdaten einspielen, sowie unsere lokale Datenbank auf den staging Server einspielen.

Die Shop URL muss noch in der s_core_shops Tabelle angepasst werden.

Und Final muss der Pfad in der Config des Webservers angepasst werden. Dieser zeigt ja auf /var/www/shopware , muss jetzt aber auf /var/www/shopware/current zeigen.

Und das war es auch eigentlich schon.

Mögliche Probleme

Die meisten Probleme die man mit Shopware und Deployment hat, liegen am Cache. Wenn man ein neues Release depoyed wird der Cache nicht geleert und im Backend wird man unter Themes sehen, dass dieser noch auf ein altes Release zeigt. Deswegen muss man immer den Shopcache leeren unter Einstellungen / Cache / Performance. Dort gibt es jedoch zwei Möglichkeiten. Einmal unter dem Reiter Start, den Cache zu leeren und einmal unter dem Reiter Cache. Beide arbeiten Unterschiedlich.

Ich habe folgendes Problem beobachtet, wenn man den Cache unter dem Reiter Cache leert, wird der Theme / Template Cache geleert und einige andere. Jedoch nicht der Backend Cache, welcher auf das falsche Release zeigt. (Im Theme Manager). Also muss man den Cache unter dem Reiter Start leeren. Dann wird der Theme Manager Cache auch geleert und zeigt auf das richtige Release. Was vorkommen kann ist jedoch, dass dadurch das Backend “zerschossen” wird. Weil der Theme Manager dann auf das neue Release zeigt, im Backend aber noch der absolute Pfad für die Backend Theme Dateien angegeben ist, die dann nicht mehr gefunden werden. Man muss dann unter dem Reiter Cache, den Cache nochmal leeren, dann wird das gefixt.

Was jedoch etwas frickelig ist, da es nicht so einfach ist durch die extjs Komponenten zu navigieren ohne Styles. Einfach ist es dann auf dem Server den Cache zu leeren. Über ssh verbinden und dann unter shared/cache/ die Datei clear_cache.sh mit sudo rechten aufrufen.

Dann sollte alles Problemlos klappen.

 

Posted by

Meistens Student. Oft Spieleentwickler und fast immer Blogger. Twitter-Junkie sowie Fotokamera halter. Meistens blogge ich weil ich nichts anderes zu tun habe. Was so viel heißt wie, ich drücke mich vor der Arbeit indem ich blogge.

  • Can

    Moin Jakub,

    danke für den Artikel, sehr hilfreich – hatte mal im Forum nach deren Projektsetups gefragt aber da kam echt nur Mist bei rum.

    Was mich interessieren würde – wie arbeitest du mit Grunt, .. lokal?

    Ich hatte bisher Shopware in einer Vagrant Box und dort dann den Grunt am laufen. Die Less Files habe ich per FTP gesynyced. Aber irgendwie gab das immer wieder kleine Problemchen – aktuell erkennt grunt zwar Änderungen an den Dateien und kompiliert darauf hin auch das CSS – dennoch wird das im Frontend nicht übernommen – ausser ich initiiere via Shopware eine “re-Kompilierung” des Themes.. grunt läuft im /theme Folder.

    • Ja, es hat mich auch gewundert, als ich damals nach Workflows und Deployment Möglichkeiten gesucht habe, dass eigentlich nichts vernünftiges zu finden war. Außer in PHPStorm Ftp Sync zu aktivieren 😀

      Die haben mit Shopware 5 ja die Sturktur der Themes geändert. Deswegen kann ich dir das gar nicht so genau beantworten. Da das Theme woran ich arbeite eigentlich ein SW4 Theme ist, welches beim SW5 Upgrade portiert wurde. Aber deswegen noch eine alte Struktur aufweist. (zB im templates Ordner nicht themes) Und da hatte ich die gruntfile vom template scaffolding repository von shopware genommen.

      Die ist bei mir unter templates/themename/ und ist eigentlich eine ganz normale gruntfile die die sachen compeliert, minified etc.

      Die aktuelle Struktur habe ich mir noch nicht genau angeschaut, mit der Theme.php und den mehreren gruntfiles. Sollte aber eigentlich ja genauso funktionieren…

      Hat der aktuell eine Versionierung der CSS Files?