Hi,
unterscheiden sich die beiden genannten Versionen eigentlich?
Also ist die aktuellste Version jetzt die Developer Version aus dem Github-Repo, oder die Early Access 1.1 Version?
Danke und viele Grüße
Hallo,
Die EA1.1 Version ist der Stand des Master-Branches zu einem festgelegten Zeitpunkt kurz vor dem Release.
Die Developer Version von Github wird aber täglich aktualisert und ist schon quasi beim Release der EA1.1 aktueller 
Wenn du also immer den aktuellsten Stand nutzen möchtest, soltest du die Github-Version nehmen. Falls du es stabiler haben möchtests, nutzt du die Release Versionen, die in regelmäßigen Abständen erscheinen.
Viele Grüße aus Schöppingen
Michael Telgmann
1 „Gefällt mir“
Korrigiert mich gerne, aber es gibt noch deutlich mehr Unterschiede. So gibt es in der EA1 kein psh.phar - Script, es gibt keine Möglichkeit ein Storefront:build auszuführen und ein Custom Theme kann ich da auch nicht wirklich einhängen. Es fühlt sich für mich so an, als ob die ea1, die man als ZIP herunterladen kann eine deutlich abgespecktere Variante ist, als einfach ein Master-Snapshot des Develop-Branches vor einigen Wochen. Die Demodaten unterscheiden sich im Übrigen auch massiv. Außerdem ist bei der einfachen EA1 kein eigenes Elastic Search angehängt, was in der Developer-Version vorausgesetzt ist, bzw automatisch mit installiert wird. Dafür lässt sie ea1 sich dockerisiert auf dem Mac extrem schnell verwenden 
(Für mich bedeutet in dieser Frage ea1 = Zip-Datei,die ich runterladen kann / Developer-Version = Variante, die aus dem Git ausgecheckt wird)
1 „Gefällt mir“
Hallo marfie,
die von dir erwähnten Dinge kommen noch dazu. Die EA Release Packages sind für den Einsatz auf Produktiv Systemen gedacht, bzw. in Umgebungen, de mal produktiv genutzt werden sollen. WIr haben dort bewusst, das komplette Tooling für die Entwicklung ausgespart. Es würde das Package nur unnötig aufblähen. Im Prinzip fehlt aber nur das, was du im Development Template findest. Dieses solltest du dann auch für die Entwicklung von Plugins nutzen 
Funktional gibt es keine Unterschiede. Warum das ElasticSearch Package fehlt, kann ich gerade nicht sagen, aber werde ich mal nachhaken.
Viele Grüße aus Schöppingen
Michael Telgmann
Hallo Michael,
wie kann ich denn ein Custom Theme mit eigenem JS und CSS aktuell auf einem solchen Produktiv-System deployen ?
Meine Erfahung bisher:
Damit die Änderungen ziehen, muss ich verschiedene bin/console-Scripte ausführen. Die wiederum funktionieren nur, wenn ein Zugriff auf die Datenbank besteht. D.h. ich muss den Theme auf dem Zielsystem kompilieren.
Das Custom Javascript habe ich nur zum Laufen bekommen, in dem ich in der Development-Version “./psh_phar storefront:build” aufgerufen habe. Das fehlt aber auf dem Produktiv-System. Ich habe mir daraus dann folgende Kombi auf dem Zielsystem zusammengestellt um das JS zu “kompilieren” : (Quasi aus dem ./psh_phar storefront:build übernommen)
bin/console bundle:dump
#Build Everything for Storefront
PROJECT_ROOT=/var/www/html/ npm --prefix /var/www/html/vendor/shopware/storefront/Resources run production
bin/console theme:compile
bin/console assets:install
Das aufgerufene npm-Script benötigt aber wiederum Sourcen, die nicht im ea1.1 Release existieren. Ich musste mir diese aus den Development bzw Platform-Sourcen zusammenkopieren.
Mittlerweile läuft damit mein Deployment flüssig durch, aber es war nicht ganz unaufwändig.
Habe ich etwas grob verkehrt gemacht, oder ist das EA-Release tatsächlich für einen echten produktiven Einsatz etwas zu sehr abgespeckt worden ?
Hallo marfie,
gedacht ist es so, dass dein Theme oder Plugin alle gebauten CSS und JS Dateien mit ausliefert. Wenn dann das Theme installiert wird, sammelt Shopware diese gebauten Dateien ein und verbandelt diese mit den bestehenden Core Dateien.
Ich will nicht ausschließen, dass das momentan noch nicht so läuft. In den nächsten 1-2 Wochen soll das nächste EA Release kommen. Vielleicht kannst du da das Deployment noch mal gegen testen. Falls es dann noch Probleme gibt, kannst du gerne ein Ticket dafür aufmachen.
Zudem wird es auch irgendwann ein Template für Production geben (analog zum Development Template), dass vielleicht für das automatische Deployment besser funktioniert.
Viele Grüße aus Schöppingen
Michael Telgmann
Danke für die schnelle Antwort. Ich warte sehnsüchtig auf das neue EA-Release
Mein Problem an eurem Konzept bisher ist, dass ich in einem Dev-Team niemals möchte, dass etwas kompiliertes eingecheckt wird, weil das extrem fehleranfällig ist. Alleine das Mergen von Branches mit minifiziertem Code ist quasi nicht möglich. Außerdem kann ein Dev-Rechner durch anderen Code so ein Kompilat “versauen”, oder er vergisst ausversehen sourcen einzuchecken und beim nächsten Build auf einem anderen Rechner ist das Kompilat dann kaputt, weil Sourcen fehlen. Es gibt diverseste Gründe, warum man für ein produktiv-System nicht lokal bauen sollte.
D.h. ich möchte das kompilieren eigentlich in meinem Build-Job im Deploy-Prozess durchführen, weil das der einzige Ort (vor dem Live-Server) ist, in dem die Sourcen gesichert den Zustand haben, den sie auch im Live-System haben (sollen).
Wenn ich das Kompilieren im Build-Job durchführe, benötige ich auf jeden Fall eine Datenbank. Daher fahre ich dafür auf dem Buildsystem einen Dockercontainer mit einer Datenbank hoch. Aber auch das ist fehleranfällig, weil ich nicht immer sicherstellen kann, dass der Datenbankstand im Build-System mit dem, auf dem Zielsystem übereinstimmt, da z.B. vom Kunden auf dem Zielsystem ein weiteres Plugin installiert wurde, welches mir dann beim Kompilieren fehlt. Somit komme ich in dem Gedankenspiel immer wieder darauf hinaus, dass mit dem aktuellen Konzept und er Implementierung das Kompilieren und Bauen der Sourcen alleine auf dem Zielsystem möglich ist.
Das waren nur noch mal ein paar Infos zu meinen Deploy-Gedanken.
Ich halte jetzt erstmal die Füße still und warte auf das nächste Release
Viele Grüße,
Markus
1 „Gefällt mir“