Magento-Entwicklungsworkflow: Wie kann man Datenbanken „Quellcodeverwaltung“ durchführen und die Magento-Live-Installation von der Magento-Testinstallation aus aktualisieren?

Ich poste diese Frage, weil ich wissen möchte, was der beste Entwicklungsworkflow für jemanden ist, der alle Aspekte eines Onlineshops verwalten möchte.

Wie bei jeder Webentwicklung ist es natürlich sehr wichtig, eine Live-Kopie und mindestens eine Entwicklungskopie der gesamten Softwarelösung zu haben. Das Verwalten von Magento-Inhalten ist jedoch nicht mit dem Verwalten anderer "dateibasierter" Software vergleichbar, da auch eine Datenbankkomponente ins Spiel kommt. Abgesehen von der Tatsache, dass ich ein Tool wie Git als VCS-Tool für die Quellcodeverwaltung verwenden kann, würde dies wie folgt aussehen Ich gehe vor, um Unterschiede in der Datenbank zwischen der Live- und der Entwicklungsversion zu verwalten.

Ich könnte natürlich Backups der Live-Datenbank über cron erstellen und die SQL INSERT-Anweisungen aus backup in die Quellcodeverwaltung einfügen, aber danach werden zwei Datenbanken separat entwickelt, während sich Kunden registrieren und Bestellungen aufgeben, die in die Live-Datenbank eingehen, und da Updates in der Entwicklungsdatenbank separat vorgenommen werden. Wenn es darum geht, Entwicklungs- und Live-Versionen zusammenzuführen, können die PHP-Dateien problemlos über git aktualisiert werden (mit gitignore auf der einzelnen Datei, die die Konfigurationsdetails der Host-Datenbank enthält), aber was ist mit den Datenbankdateien? Wie kann ich die beiden Dateien, die INSERT SQL-Anweisungen enthalten, aus den beiden Sicherungen zusammenführen, ohne einen Notfall zu verursachen und das System zu beschädigen?

Dies ist der dunkle Bereich des Magento-Entwicklungslebenszyklus, mit dem ich konfrontiert bin: das Verwalten von Datenbankunterschieden.

Es scheint mir, als ob die einzige Lösung für die Synchronisierung der Datenbankinhalte, die sich zwischen der Entwicklungs- / Test- und der Live-Version des Magento-Stores unterscheiden, darin besteht, alle Änderungen, die in der Entwicklungsversion über das Magento-Admin-Panel vorgenommen wurden, auf ein Blatt Papier zu schreiben. und hoffe, keine Fehler zu machen, und dann, sobald alles getestet und die Arbeitsdatei erstellt ist, zur Live-Version überzugehen und genau die gleichen Änderungen vorzunehmen, während Magento offline geschaltet und in den Wartungsmodus versetzt wird. Da dies ein manueller Vorgang ist, ist er fehleranfällig.

Was ist also die bessere Möglichkeit, die Datenbanksynchronisation zwischen dem Test-Magento-Server und dem Live-Magento-Server durchzuführen?

Vielen Dank.

Optionen, die mir bekannt sind

1.) Manuell - Mit anderen Worten: Wiederholen Sie Ihre Aktionen manuell im Backend = Wie Sie bereits erwähnt haben, fehleranfällig, langsam

2.) Auf Datenbankebene mit direkten SQL-Abfragen = fehleranfällig

3.) Erstellen Sie eine Erweiterung, die Änderungen über SQL Setup / Upgrade-Skripte hinzufügt. Diese Dateien sind Teil Ihres Repositorys und können bereitgestellt werden. Dieser Ansatz umgeht meist die Benutzeroberfläche.

4.) Es wurde versucht, einen Teil dieses Workflows in Projekten wie diesem angenehmer zu gestalten , aber ich denke, es ist noch nicht ganz bereit für die Hauptsendezeit.

Von all diesen Optionen bevorzuge ich derzeit 3.)

Es gibt auch Mitarbeiter, die dieses Problem lösen könnten.

Es gibt Datenbanktools wie Toad for MySQL von Quest Software (jetzt Dell). Dieses Datenbankverwaltungstool verfügt über Daten- und Strukturvergleichsfunktionen, mit denen Sie Änderungen zwischen zwei Datenbanken anzeigen können. Bewahren Sie einfach Backups (oder git-Commits) der zu vergleichenden Datenbankversionen und von voila auf. Es gibt sogar einen Skriptgenerator, mit dem die beiden synchronisiert werden können.

Wir haben dieses Problem gelöst, indem wir eine Remote-Datenbank erstellt haben, in der die lokalen und Staging-Entwicklungen gelesen / geschrieben werden können. Hilft wirklich mit Zeit und Effizienz; Kein Klonen mehr, Hochladen der Datenbank in die Umgebung aller.