wir sind gerade dabei uns intensiv Gedanken um eine geeignete Infrastuktur zu machen, um eine dauerhafte Staging-Live-Lösung zu finden. Das klassische Modell ist ja zusätzlich zu einer Live-Instanz eine Staging-Instanz zu haben, welche in einem Unterordner (staging) läuft. Um dieses zu erstellen, gibt es diverse Plugins oder man erstellt diese selbst.
Optional kann noch eine oder mehrere lokale Entwicklungsinstanzen hinzukommen. Für die Deployments nutzen wir GIT, um den Code zu Versionieren. Was wir hier gerne optimieren würden, ist zum Beispiel auch die Übernahme von Konfigurationen, welche bereits auf der Staging gemacht wurde und dann automatisiert auf Live deployed werden kann.
Durch die Lizenzierung von Shopware und deren Plugins müssen die Instanzen unter der selben Domain laufen. Hierbei ist uns z.B. aufgefallen, dass es hier durchaus zu Nebeneffekten kommen kann, da ja beide Instanzen dieselbe Cookie-Domain verwenden.
Wir spielen mit dem Gedanken weitere Instanzen parallel laufen zu lassen, z.B. wenn es einen Support für einen Plugin-Hersteller gibt, dass dieser eine eigene Instanz erhält.
Uns würde interessieren wie ihr eure Instanzen aufbaut und freuen uns über einen interessanten Austausch
Schliesse mich der Frage an, das mit der Domain ist schon etwas schwachsinn, wer lässt einen Shop unter dev.xy.de, xy.local laufen? Shopware sollte sich da Grundlegen gedanken machen! Den Shop unter xy.de/dev laufen zulassen ist für mich keine Lösung. Also lasst uns bitte eine Dev/Staging und eine Live Domain registrieren!
Bei anderen Applikationen wie TYPO3 haben wir ein vollständiges Deployment, mit Gitlab CI und mehreren Docker Instanzen. Mit Shopware nicht mögliche, oder?
Bei Shopware 5 wie aber auch bei vielen anderen Datenbank basierten Systemen ist ein sauberes Deployment samt DB ein Graus.
Hängt einfach damit zusammen, dass du eben deine Live Datenbank hast und deine „Staging“ Datenbank. Dann hat Entwickler A noch eine lokale Installation und Entwickler B usw.
Deployment via CI, Docker usw. ist natürlich möglich, aber eben auch aufwendig das alles sauber ans laufen zu bekommen.
Du musst die Plugis aussortieren, ggf. Theme, Datenbank usw. Aber auch hier ist das Problem immer die Datenbank.
Es gibt da leider nicht DIE Lösung. Dieser „Staging“ Weg bei Shopware ist ja auch nicht wirklich eine „Staging“ Umgebung. Es ist einfach nur eine Kopie vom Shop, wo man eben alles doppelt gemoppelt machen muss
Unabhängig von Shopware habe ich aber auch noch kein wirklich sauberes Deployment kennen gelernt bei Datenbank basierten Systemen, da du halt immer die Datenbank dazwischen hast - Das ist das größte Manko.
Das mit der DB haben wir im Griff, einzig bei Updates an der Live Umgebung am Shopware Core haben wir eine kurze Downtime. Wir nutzen für Plugins. Themes jeweils eigene Branches. Das problem kommt bei der Lokalen Entwicklung von Plugins, inkompatiblität, testing das lässt sich lokal nicht machen ohne Lizenz! Ich weiss man kann die Hosts Datei anpassen und die Domain Faken, aber auch das finde ich nicht Elegant. Shopware ist das sicher auch bekannt und dürfte hier doch die Zügel lockern -> 2. Domain für Staging/Dev 3. Localhost !!
Ich sehe nur einen Grund warum das Shopware nicht anbietet, es steigert den Umsatz. Wir haben etliche Plugins 2x gekauft so das wir min. die Staging Umgebung Lizenziert haben.
Den Shop unter xy.de/dev laufen zulassen ist für mich keine Lösung.
Aus meinen bisherigen Erfahrungen (und wir haben schon viele Shops umgesetzt) ist es eine gute Lösung, jedenfalls besser als dev.xy.de
Lokale Lösungen kommen nie in Betracht, denn der Shop soll schon unter reellen Bedingungen laufen. Weiterhin sieht der Kunde auch den Forstschritt der Entwickelung und kann sogar parellel seine Produkte schon einpflegen (sofern nötig). Und nicht zuletzt auch der Aspekt, dass teilweise viele Plugins zum Einsatz kommen die ggf. vorher geteset werden müssen. Dann ist das gut, wenn dies schon über die Hauptdomain (die ja schon bei Shopware registriert ist) getan wird. Dann muss man Lizenzen nicht doppelt erwerben.
Natürlich ist das alles davon abhängig was man machen möchte. Ist es ein komplett neuer Shop oder ein Update mit neuen Design. Mit irgendwelchen Test-Subdomains haben wir zumindest schlechte Erfahrungen gemacht.
Aber ok, über diese Thematik muss nicht weiter diskutiert werden, hierzu gab es schon Beiträge und Kommentare.
Du hast mich falsch Verstanden, die DEV Umgebung haben wir komplett getrennt von der Live Umgebung, diese im Unterverzeichnis abzulegen naja… sicher nicht Best Practice. Die Dev Umgebung kann identisch sein somit kannst du unter “Reellen” Bediengungen Entwicklen, wenn das Plugin unter www.xy.com funktioniert dann unter jeder Subdomain, leider macht da Shopware einem ein Strich durch die Rechnung. Dafür stimmt Ihre Rechnung, das Lizenz Model ist für mich Umsatz optimiert! Das wird auch einer der Gründe sein warum sich Shopware dazu fast nicht äussert.
Wir synchronisieren die DB rückwärts, also von Production auf Dev/Staging. Bei einem Shopware Update mit Composer haben wir eine kurze Downtime, damit können wir leben.
Für das Deployment nutzen wir Gitlab mit CI - als Server Umgebung setzen wir Jelastic PaaS ein. Mit rSync wird das ganze vom Gitlab auf den Server kopiert. Zero Downtime.
Lokal arbeiten wir alle mit einem Docker Container, dieser wird mit dem Projekt Versioniert. Jeder Entwickler hat somit die gleiche Umgebung. Mit Docker-Sync auf OSX läuft das ganze dann auch sehr flot…
In etwa so wie im Link unten, wir haben einfach eine angepasste erweiterte Config… da wir diese Lösung auch für typo3 einsetzen.
