Datenbankmigration von Development nach Live: Best Practice?

 Hallo zusammen,

ich hab hier ein größeres Update auf die aktuelle Shopware-Version anstehen. Da ich das ungern einfach auf dem Live-Server ausführen und dann am offenen Herzen Fehler beheben möchte habe ich mir die Vagrant-Testumgebung von https://github.com/shopwareLabs/shopware-vagrant installiert.

Der Code der Live-Umgebung liegt bereits in einem Github-Repo und kann daher auch problemlos von Vagrant ausgecheckt und genutzt werden, die nach dem Update geänderten Files kann ich problemlos wieder comitten und pushen. Mein eigentliches Problem sind die Datenbankänderungen, die diese Version ja sicherlich mit sich bringen wird. Woher weiß ich, was das Update an der Datenbank ändert und wie bekomme ich diese Änderung deployed? Das gleiche gilt für das Update von Plugins. 

https://developers.shopware.com/sysadmins-guide/professional-deployments/ kenne ich. Da steht aber nichts drin wie man für die Datenbank vorgeht…

Gruß

Matt

Hi @msslovi0‍,

da gibt es einige Ansätze die mir da auf anhieb einfallen würden.

Grundsätzlich sollte man aber hier verschiedene Shopware Versionen voneinander trennen. Also nicht einfach alles ins Master pushen und ende. Eigene Datenbankänderungen würde ich bis ins kleinste Details dokumentieren oder zumindest das Resultat abspeichern, dass z.B. PHPMyAdmin ausliefert. Hier kannst du dann daraus ein Update für die Datenbank basteln.

Es gibt aber auch Alternativen wie z.B. SQLyog. Hier gibt es in der Pro Variante mehrere nützliche Tools um Veränderungen von Datenbank A zu Datenbank B festzustellen. Unter anderem das “Schema Synchonisation Tool” dass die nicht nur Datenbankänderungen anzeigt sogar gleich die richtigen Statements um das Ziel entsprechend anzupassen. Aber ein 1A Lösung ist das auch nicht, wenn sich ein Spaltenname ändert. Denn dann wird die alte Spalte gelöscht und eine neue erstellt, aber der Inhalt wird nicht entsprechend angepasst.

Ich persönlich würde immer in der gleichen Shopware Version an Shopware entwickeln. Gibt es ein Update, dann würde ich auch zugleich die Testumgebung updaten. Damit alle mit entwickeln können, würde ich dann auch je Shopware Version ein SQL-Dump abspeichern und dann jede Datenbankänderungen in einer gesonderten Datei ablegen. Dann könnte auch jeder auf den gleichen Stand upgraden.

Ich versuche es mal Visuel darzustellen:

  1. Shopware Version 5.5.0 
  2. SQL-DUMP
    1. Commit 1
    1. SQL Änderung 1
    2. SQL Änderung 2
    3. SQL Änderung 3
2. Commit 2 
  1. SQL Änderungen 1-10
  1. Shopware Version 5.5.1
  2. SQL-DUMP
    1. Commit 1
    1. usw.

Eventuell hilft dir das ja weiter. Wahrscheinlich gibt es hier aber noch genug Leute die da sehr viel mehr Erfahrung haben dir noch weitere Ideen liefern können.

Nachtrag: Aber schau dir auch gern mal an, wie das Shopware z.B. in bei einem Update löst. Das schaut so ähnlich aus: https://de.shopware.com/download/ im Ordner->update_assets->migrations

VG

ener Space  Webhosting
Tel.: +49 511 - 999 791 70 | Web: https://www.enerspace.de

@enerSpace schrieb:

Es gibt aber auch Alternativen wie z.B. SQLyog.

Danke, das schau ich mir mal an.

@enerSpace schrieb:

Gibt es ein Update, dann würde ich auch zugleich die Testumgebung updaten.

Aber das ist ja genau mein Punkt. Ich will ja zunächst mal nur die Testumgebung updaten, um zu sehen, ob dann noch alles funktioniert. Und wenn alles funktioniert das dann nach Live spielen. Wenn ich aber in Shopware auf „Aktualisieren“ drücke habe ich keine Info darüber, was genau an der Datenbank geändert wurde. Wenn ich direkt auch Live aktualisiere kann ich mir hingegen die Testumgebung direkt sparen.

Das mit den Migrations ist nett, aber wenig hilfreich. Da sind derzeit 1461 Migrations drin, aus der Bezeichnung geht nicht hervor, welche ich anwenden muss für ein Update von 5.4.5 auf 5.5.8. Und selbst wenn es da ein Indiz für gäbe, spätestens bei den Plugins ist Schluß (und gerade Amazon Pay will man nicht einfach mal so upgraden, da geht normalerweise immer was kaputt…)

Matt

Hi,

@msslovi0 schrieb:

Und selbst wenn es da ein Indiz für gäbe…

Den gibt es sogar direkt in der Datenbank: s_schema_version. Hier werden für den Updater die einzelnen Schritte abgelegt. Dann weiß Shopware, wo das Update weiter machen soll, wenn es unterbrochen wurde.

Ich verstehe worauf du hinaus möchtest. Mir ist da aber keine Löung bekannt, wo man einfach hin und her wechseln kann, außer man nimmt einen kompletten Dump oder speichert zumindest die Tabellen ab die sich geändert haben. Aber dieses Dumps müssen entsprechend immer wieder aktualisiert werden, wenn dort auch Kundendaten oder Bestelldaten einfließen.

Mit SQLYog lassen sich einige Änderungen von Plugins feststellen. Wobei die Plugins meistens immer eigene Tabellen haben. Aber auch das ist meiner Meinung nach zu aufwändig.

Normalerweise werden die Plugins vor dem eigentlichen Update aktualisiert. Aber es gibt auch Plugins die hinterher aktualisiert werden müssen. Per Console ginge dass auch automatisiert. Ich würde die einzelnen Prozesse strikt voneinander trennen und für jedes Problem einen eigenen Update-Prozess entwickeln.

Aber an Dumps die zur entsprechenden Version passen, wirst du wohl nicht vorbei kommen.

VG

ener Space  Webhosting
Tel.: +49 511 - 999 791 70 | Web: https://www.enerspace.de