Shopware 6 | Minor Update mit Github production Template

Einige von euch setzen eventuell bereits das production Template von Shopware. Hier möchte ich kurz zwei Wege aufzeigen, diese upzudaten. Denkt bitte an die Umfrage am Ende auszufüllen 😉

production Template

Wer nicht den Standardweg über Zip Download und simples Webhosting geht, greift meist auf das production Template zurück. Hast du einen einfachen Shop mit einem Server / Webhosting Paket, ist das hier vermutlich nicht interessant für dich.

https://github.com/shopware/production

„This template is optimized for production usage and contains basic development tooling. It’s intended as a basis for project customizations, which are usually done by agencies.“

Eigene Plugins installieren

Hier habt Ihr die Qual der Wahl, Shopware selbst schreibt dazu:

static-plugins

Die Plugins in static-plugins abzulegen hat den Vorteil, dass Ihr kein externes (privates) Repository einbinden müsst und euch damit das taggen etc. spart. Allerdings auch den Nachteil, dass Ihr dann entweden mit Submodulen arbeiten müsst, oder immer euren Pluginordner syncen müsst und damit dann keine Versionierung direkt im production Projekt habt.

Private Repositories

Bezüglich Versionierung, Updates und Convinience finde ich persönlich die private Repo Lösung besser. Damit setzt Ihr auf die saubere Lösung mit Tags (git tag -a v1.4 -m „my version 1.4“), könnt direkt im Projekt eure einzelnen Plugins schön mit Git bearbeiten und könnt auch mehrere production Projekte ohne viel Aufwand pflegen. Nachteil ist hier, dass ihr euch Gedanken um die Einbindung der Repos und deren Freigabe nach außen machen müsst (wir geben diese aktuell explizit für Server / SSH Keys frei).

Minor Update

In der Regel speichert ihr das production Template/Repo in eurem eigenen Fork oder Git Tool (Github, GItlab, Bitbucket etc.). Das heißt Ihr habt euren master/branch irgendwann hinter dem eigentlich SW Repo und das führt dann beim Update von Shopware dazu:

composer update "shopware/*"

...

In FeatureConfig.php line 29:
Unable to retrieve flag FEATURE_NEXT_10286, not registered  

Also was müsst Ihr machen? Ihr fetched euren vorher angelegten upstream und merged danach die von euch gewollte Version (in meinem Fall 6.3.1.1)

git merge upstream/6.3

Eventuell wollt Ihr noch –no-ff (damit nicht automatisch gemerged wird) oder –allow-unrelated-histories nutzen.

Natürlich kommen jetzt einige Merge Konflikte. Bei mir sieht das ganze dann so aus:

Eine composer.lock zu mergen macht def. keinen Spass (und ist auch nicht empfohlen), daher meine Empfehlung löscht diese vorher und baut euch ein Script welche eure externen Repos wieder required und damit dann in die composer.lock schreibt.

Eigentlich solltet Ihr hier nur die composer.json per Hand mergen müssen, den Rest könnt Ihr (nach eurer Prüfung) einfach mit Accept Theirs rüberziehen. Wir haben unsere build und devops Skripte alle in bin/ liegen und entsprechend neu benannt (je nach Projekt übergeben wir die Projekt URL und damit wird dann die projekt.cnf geladen in der alle fixen Parameter stehen).

Jetzt löschen wir noch unseren vendor Ordner und führen dann erneut das update aus:

rm -rf vendor
composer update "shopware/*"

Jetzt sollte euren SW Repos geupdated werden und gleichzeit auch alle anderen installiert werden. In meinem Fall läuft auch gleich ein Patch mit rein

Sollte es euch mit Core Bugfixes von Shopware nicht schnell genug gehen, empfehle ich euch den Patch Beitrag.

Migrations sind auch sauber durchgelaufen, jetzt nur noch schnell in Admin schauen und wir sind durch!

Vorher wollt Ihr vielleicht noch ein ./bin/build-js.sh durchlaufen lassen, just to be sure. Und nicht vergessen euren Browsercache (Cookies/Storage) zu leeren!