Exportieren von Admin-Panel-Einstellungen, die in der Datenbank gespeichert sind

Question

Wie können Sie beim Umgang mit verschiedenen Umgebungen für Entwickler- und Live-Sites Änderungen, die nur in der Datenbank gespeichert sind, an die andere Umgebung weitergeben, ohne die exportieren zu müssen ganz datenbank?Angenommen, ich habe eine Erweiterung deaktiviert, den Inhalt eines statischen Blocks geändert, eine neue statische CMS-Seite erstellt, eine neue Versandart, Steuerregel hinzugefügt oder was auch immer. Wie gebe ich solche kleinen Änderungen an die Live-Site weiter, ohne die gesamte Datenbank exportieren und importieren zu müssen? Offensichtlich gibt es Informationen auf der Live-Site, die ich nicht überschreiben möchte.

Ich bin mir sicher, dass jemand anderes darauf gestoßen sein muss, besonders bei der Verwendung von Versionskontrolle.Wir haben Git implementiert, aber das funktioniert nur für Änderungen auf Dateiebene.Die Dateien in beiden Umgebungen können genau gleich sein, aber einige Konfigurationen in der Datenbank können sich ändern, sodass sie sich unterschiedlich verhalten.

Ich könnte alle Änderungen, die ich im Admin-Bereich vornehme, nachverfolgen und sie dann in der anderen Umgebung reproduzieren, aber das scheint sehr unpraktisch zu sein.Die Anzahl der Änderungen kann ziemlich groß sein, da wir die Website kontinuierlich zu unserer Zufriedenheit optimieren.Außerdem arbeiten auch andere Entwickler, und wir haben sogar eine Umgebung für ausgelagerte Entwickler und technischen Support von Magento-Erweiterungsanbietern eingerichtet.Ich kann nicht alles verfolgen, was sie tun.

Ich habe Tonnen von Beiträgen nur zum Export von Produkten gesehen, das ist also nicht wirklich das Problem.Ich würde es gerne andersherum haben. Vielleicht hat jemand eine Liste aller Tabellen erstellt, die zum Klonen einer Magento-Site erforderlich sind ohne produkte und Bestellungen und Kundeninformationen. Einfach alles, was im Admin-Panel konfigurierbar ist.

Hat das schon mal jemand gemacht?

---

UPDATE: Für die Leser markiere ich @ mbalpardas Antwort auf manuelle Bereitstellungsdateien als akzeptiert, bis etwas anderes auftaucht, das den Anforderungen entspricht.Ich werde erzwingen Sie Regeln, um die Änderungen im Admin-Panel von allen beteiligten Entwicklern zu protokollieren wir haben also eine einheitliche Liste am Ende.Es ist eigentlich nicht die Antwort auf die Frage, aber es ist die Methode, mit der ich das lösen werde, bis ich einen besseren Prozess gefunden habe.

Answer 1

core_config_data und core_resources sind zwei gute Orte, um zu beginnen. CMS_ * sollte die meisten der relevanten Informationen zu Blöcken, CMS und Widgets haben. Neben diesen Tabellen haben die meisten Core_ * -Tabellen einige relevante Informationen über die von Ihnen ausgeführte Website.

Die Liste ist alles andere als alles andere.

Eine andere gute Option besteht darin, eine Version der Datenbank in git zu halten und ein Diff-Tool zu verwenden, um zu sehen, was zwischen den Releases geändert hat, aber es hat möglicherweise einige Sicherheitsfragen, da persönliche Informationen in der Repo sein könnten.

Eine gute Praxis, die ich oft benutze, ist, über eine manuelle Bereitstellungsdatei zu verfügen, um alle Änderungen zu speichern, die wir in einer anderen Umgebung erstellt haben. Sobald der Code bereitgestellt wird, ist der nächste Schritt, um die manuelle Bereitstellungsdatei zu überprüfen, ob etwas sein muss, ob etwas sein muss getan. Dies wird in Fällen verwendet, in denen nicht alle Änderungen mit SQL / Daten-Updates getroffen werden können, der reguläre Magento-Weg, um SQL / Datenänderungen vorzunehmen.

Als Hinweis, Verschieben der Datenbanken zwischen Umgebungen ist nicht immer die beste Wahl, da Änderungen, die ein Administrator in der Live-Site vorgenommen hat, verloren geht, wenn sie nicht in der in der anderen Umgebung verwendeten DB repliziert werden.

Answer 2

Die Magento-Datenbank ist nicht Ihre übliche Datenbank.Es ist groß und kompliziert.
Teile davon von einer Umgebung in eine andere zu verschieben, ist keine leichte Aufgabe.
Deshalb vermeide ich normalerweise, Konfigurationseinstellungen zu ändern oder Blöcke und / oder Seiten manuell hinzuzufügen.
Ich lasse den Client das nur auf dem Live-Server machen.

Was ich während der Entwicklung tun muss, mache ich über Upgrade-Skripte.
Auf diese Weise ist alles versioniert und portabel.
Ich weiß, dass es eine Art Drag ist, ein Upgrade-Skript zu schreiben, nur um beispielsweise den Listenanzeigemodus für Produktseiten zu entfernen, aber ich habe bisher keinen besseren Weg gefunden.

Hier ist ein kleines Beispiel, wie Sie eine Konfigurationseinstellung per Upgrade-Skript ändern können.

Folgendes ermöglicht den Flatrate-Versand:

$path = 'carriers/tablerate/active';
$config = Mage::getModel('core/config_data')->load($path, 'path');
$config->setValue('1')->setPath($path);
$config->save();

Ich denke, das könnte funktionieren, wenn Sie es in ein Upgrade-Skript einfügen sql/[resource_name_here] aber für die Datenmanipulation benutze ich data/[resource_name_here].

Hier ist ein anderes Skript, das einen statischen Block hinzufügt.

$block = Mage::getModel('cms/block');
$block->setTitle('Some title here');
$block->setIdentifier('identifier_here');
$block->setContent('This is the content');
$block->setStatus(1);//enabled
$block->setStores(array(0)); //make it available in all stores
$block->save();

Sie können dies grundsätzlich für jede Entität tun, die Sie haben.

Answer 3

Ich habe ein schönes Werkzeug gefunden, um Konfigurationseinstellungen zu exportieren und zu importieren https://github.com/zookal/Harrisstreet-IMPEX

Das ist viel von dem, was Sie suchten, und ich suche nach mir.