Shopware-Blog-1

Erste Schritte – ein Magento-Mensch auf dem Weg zu Shopware 6. Heute: welches Template hätten Sie denn gern? Production oder Development?

Shopware 6 Reihe: ist das hier ein Tuturial?

Die soll eine Reihe werden. Weil ich hoffe, dass ich viel begreifen werde, das niederschreibwürdig ist. Es ist mehr ein Reisetagebuch, denn ein Turorial. Aber wenn jemand doch was mitnimmt oder mitbegreift, freu ich mich.

Als ich in meinen Magento-Anfängen über Magento-Anfänge bloggte und diese Jahre später nochmals las, dachte ich: uiuiui. Das war aber noch an manchen Stellen sehr anfängernaiv. ich hab mich aber entschlossen diese Beiträge nicht zu löschen und das auszuhalten. Ich nehme an, mit dieser Shopware-6-Anfängerreihe wird es mir ähnlich gehen und ich halte das jetzt schonmal aus 🙂

Wenn man die letzten Jahre so ziemlich die gesamte Zeit mit Magento 1 verbracht hat und nun in die Welt der eCommercesysteme da draußen schnuppert, fühlt man sich wie ein Dinosaurier. Ich sach nur: Prototype.

Man hatte zwar mal was mit Composer zu tun, aber so richtig viel Gründe das zu nutzen hatte ich nicht. Und so grabe ich mich langsam an Shopware 6 heran und bin bereit mir die Blöße zu geben, herauszuschreiben, was ich so alles nicht begriffen oder nicht gewusst habe.

(Ich bin Mac User. Das vielleicht vorweg. Das bedeutet: hier wird das Wort „Docker“, auch wenn ich langsam begriffen habe, dass das ein Zauberwort ist, vermutlich nicht nochmal auftauchen.)

Heute:

Welches Repository nehm ich denn? Production oder Development?

Also ich bin ja Entwickler. Daher fand ich es naheliegend, dass ich die Developer Umgebung nutze. Oder nicht? Wo ist denn überhaupt der Unterschied? Und wo nutze ich was?

Ich dachte also, ich als Entwickler nutze das Development Repository (https://github.com/shopware/development) und arbeite dann brav darin rum und pushe irgendeine abgespreckte Variante live, weil die Sachen, die ich nur zum Entwicklen brauche, irgendwie .gitignored werden.

So isses nich.

Was ich herausgefunden habe:

Die Repositories oder „Templates“ liegen auf Github rum (weil Dinge auf Github halt so rumliegen) , so liegt das Production Template z.B. hier: https://github.com/shopware/production

Irritierenderweise wird die Readme nicht immer aktualisiert. So klone ich aktuell die Version 6.2., in der Doku steht aber noch die 6.1. Also nicht davon irritieren lassen. Klonen und wird schon.

Man nimmt für das Livesystem also Production und nicht Development.

Das klingt jetzt simpler, als ich es empfunden habe. Denn wenn man mit Magento 1 arbeitet, benutzt man ein System und arbeitet im develop-Branch, wenn man denn eine Extension erstellt. Aber doch nicht in einer anderen Installation …

Hier läuft es so (was ich nach eifrigem Rumfragen, Artikel lesen, Podcasts hören behaupten kann):

Wenn man einen Shop aufsetzt, nutzt man das Production Template (dass es Template heißt, finde ich immer noch so überaus verwirrend). Man arbeitet an diesem und nutzt dieses auch für den Dateiabgleich zwischen Staging, lokaler Umgebung und Livesystem.

Das Development Template nutzt man dafür, um eigene Plugins oder Themes zu entwickeln. Dies tut man also gar nicht (zwingend) in der Installation, die auch live genutzt wird. Das war für mich ein völlig neuer Ansatz, an den ich mich erstmal gewöhnen muss. Aber ich gehe hoffnungsfroh davon aus, dass die Plugins in Shopware die Tendenz haben, ohne viel Gerappel mit anderen Plugins zu funktionieren. Das sieht bei Magento ja oftmals etwas anders aus. Eine Extension dort in einem blanken, vom Liveshop unabhängigen System zu entwickeln – hätte mich Kichern lassen.

Und was ist mit der Staging?

Eine Frage, die auch auftauchte: und was ist mit der Staging? Wird dort production oder developement installiert? Aller Logik nach: production (auch nach Rückfrage bei kundigen Menschen). Weil man Development halt nur zum Entwickeln braucht und in der Staging wird ja weniger entwickelt, denn getestet.

Warum diese zwei Versionen?

Das hab ich mich auch gefragt … Im Development Template sind ein paar zusätzliche Dinge enthalten. U.a. die psh.phar und allerlei andere Dinge, die man für das Entwickeln braucht (oder nutzen kann/sollte) und die das Livesystem aber nur unnötig aufblähen würden.

Diese psh.phar (wer sie nicht kennen sollte) ist ein PHP Archiv, das im Grunde funktioniert wie jar in Java. In dieser enthalten sind allerlei Befehlssätze für die Nutzung von Docker (ha, hab ich das Wort doch nochmal verwendet), um die Storefront zu „builden“ oder den Cache zu erneuern.

Wer da mal reingucken will:

Shopware Developement psh.phar

Die wesentlichen Unterschiede: psh.phar, der dev-ops-Ordner und der Ordner „platform“.

Im Dev-Ops Ordner findet man Entwickler-Werkzeuge. (Contains utilities for deployment, development and continuous integration.)

Im Order „platform“ findet sich der gesamte Core-Code von Shopware 6. Wenn man gerne am Core mitarbeiten möchte, kann man das dort im Grunde tun (Zauberwort: pull request).

Einen kundigen Shopware-Menschen befragt, was denn der Grund für diese Trennung ist (ich würde davon ausgehen, dass man sich im für-alle-gleich-Shop einfach zusätzliche Developer-Tools installiert, die nicht mit ins Livesystem geladen werden), erhielt ich diese Antwort:

Wie jeder vielleicht weiß, basiert Shopware unter anderem auf Symfony. Bei dem „Template“ handelt es sich daher um eine minimale Symfony-Umgebung, die entsprechend „Shopware“ lädt. Die Idee hinter diesen Templates war, dass man im Grunde eigene Templates baut und die vorhandenen „nur“ als Grundlage dienen für die eigenen Anpassungen. Man ist damit zum Beispiel unabhängig vom Frontend und kann das ganz weglassen oder nutzt stattdessen PWA – ohne dass man irgendwas aktiv „ausbauen“ muss.

.git und .gitignore

Ich schaue mir zunächst das Production-Template weiter an. Und als Magento-Mensch bin ich zunächst irritiert über die Fülle an .gitignore-Files. Und überhaupt, ist da ja ein Branch und ein „origin“ Remote. Was mache ich mit „meinem“ Git und wieso wird hier so viel ignoriert?

Diesen Fragen bin ich schon nachgegangen. Und die Antworten schreibe ich alsbald hier nieder …

Kontakt
E-Mail: office@neoshops.de
Tel.: +49 [0]151 7000 7107
Carmen Bremen
Magento Certified Developer
Magento Certified Solution Specialist
Magento Certified Frontend Developer
Magento Freelancer


Magento Certified Developer Magento Certified Solution Specialist Magento Certified Frontend Developer



Magento Stammtisch Köln
Magento Stammtisch Köln
Der nächste Kölner Magento Stammtisch findet statt am 29. April 2020. (Xing Event) Wer Interesse hat, kann sich in die Stammtisch-Gruppe auf Xing eintragen, ich sende eine Rund-E-Mail mit Details kurz vor dem Event!

Kontakt

Carmen Bremen.

In: Xing
In: Skype
In: Twitter
In: Google+
Per: Formular
Innermail: Office (t) neoshops.de
In Köln: In der Lößbörde 1, 50859 Köln
Per Handy: +49 [0]151- 7000 7107

Letzte Beiträge