ich tu mich schwer, mit SW6 aus Entwicklersicht warm zu werden. Ich glaube mir fehlen hier noch ein paar Grundverständnisse. Wie bekomme ich sinnvoll eine lokale Entwicklungsumgebung auf den gleichen Stand wie die Liveumgebung bzw. wie sieht bei SW6 ein richtiges Deployment aus?
Aus der alten Magento 1.9 CE Welt, ist evtl. mein Denkansatz noch falsch. Wir haben uns eine composer.json gebaut, über die wir Magento, Community Plugins, eigene Plugins und alle Abhängigkeiten installiert haben. Gab es für Community Plugins mal kein public Git Repo, haben wir eben selber ein internes angelegt. Alle Versionen konnten darüber einfach gesteuert werden. DB kopieren, git clone unseres eigenen Repos mit composer update, dass alles gezogen hat. local.xml (bei SW wäre das dann .env) anpassen und per kleinem SQL Script, noch ein paar wenige Werte, wie Domain, in der DB updaten. Das ging sowohl als Entwickler lokal zuverlässig und schnell, als auch über Jenskins für ein Live-Deployment.
Wahrscheinlich mache ich noch etwas falsch, denn momentan fühlt sich das nach basteln und nicht nach arbeiten an.
Wozu wurde denn das Git-Repo so aufgeteilt, dass ich innerhalb des Projektes nochmal git clone ausführen muss?
Wie kann ich Plugins via Git bzw. Composer installieren, um überall die 100% gleiche Codebasis zu garantieren?
Ich kann mir ja nicht vorstellen, dass man das immer per Hand installieren muss oder am Besten noch wie vor 20 Jahren via FTP den Code kopieren.
Wie kann ich die Live-Datenbank kopieren und zB. lokal nutzen. Insbesondere auf Hinblick der Plugins, die Einträge in der DB erzeugen.
Ich habe zB. einen blanken SW6 Shop installiert. Alle Sprachpakete haben natürlich andere lang_id, local_id usw. Entsprechend kann ich Saleschannels, Produkte, … nicht einfach aus einer bestehenden SW6 DB übernehmen. Wenn ich hingegen erst die DB kopiere, wie installiere ich dann SW6 mit allen Plugins, ohne das hier etwas an den DB-Einträge verändert und damit unbrauchbar gemacht wird?
Hi, würde mich der Frage anschließen.
Besonders nachdem es jetzt das production template gibt.
Brauchen wir zum entwickeln beide repos? developer für Local und Testumgebung, production für live?
Allgemen ein Beispielablauf von lokal entwickeln über testen auf Testumgebung bis hin zu deployment auf Live wäre nett. Eventuell noch dazu was wir alle mit z.B. git tracken sollen.
wenn ich das richtig sehe, „fehlen“ der Production-Variante z.B. die ‚./psh.phar‘ + dazugehörige commands - also z.b. storefront:build. Der ganze dev-ops kram ist ebenfalls nicht vorhanden. Also ja, ich würd mal sagen, dass das production-template ein Produktivsystem errichtet. Zum entwickeln empfiehlt es sich dann eher, im development-template zu bleiben. zum testen… naja… je nach gusto, würd ich mal vermuten.
Zum deployment haben sich, afair, die jungs (und mädels?) von FROSH gedanken gemacht, ich weiß nur nimmer, wo das hier im Forum zu finden ist.
@Shyim weiß da sicher mehr. (da war doch was mit plugins per composer und so…)
vielleicht habe ich da ein gänzlich falsches Verständnis von Deployment-Prozessen.
Eigene Templates & Themes können/sollten via Development Template betrieben werden und können via git push und entsprechender Deployment-Toolchain entsprechend ins Live System gepushed werden. Der Checkout selbst läuft via dediziertem Plugin und Theme.
Der Unterschied zwischen Development-Template und Production-Template ist, dass einige Dinge in Production nicht zur Verfügung stehen.
Will heißen, live gibts das production template, welches die Plugins via git/deployment erhält. Die Abhängigkeiten der Plugins werden in den Plugins selbst, da Symfony-Bundles, verwaltet/gehandhabt.
Aus Datenschutz-Sicht sind Kunden-Daten, bzw. Live-Daten nicht im Testsystem zu halten, oder zumindest anonymisiert.
In der kommenden Shopcast.fm Episode werden wir auf genau diesen Vorgang eingehen und von unterschiedlicher Seite beleuchten. Die Krux ist nur, dass es keinen „einen richtigen Weg“ gibt.