Вопрос

При работе с разными средами для сайтов разработки и действующих сайтов: как передавать изменения, которые сохраняются только в базе данных, в другую среду без необходимости экспорта весь база данных?Скажем, например, я отключил расширение, изменил содержимое статического блока, создал новую статическую страницу CMS, добавил новый метод доставки, налоговое правило или что-то еще. Как мне перенести подобные небольшие изменения на работающий сайт без необходимости экспортировать и импортировать всю базу данных? Очевидно, на действующем сайте есть информация, которую я бы не хотел игнорировать.

Я уверен, что кто-то еще столкнулся с этим, особенно при использовании контроль версий.Мы реализовали git, но это работает только для изменений на уровне файла.Файлы в обеих средах могут быть абсолютно одинаковыми, но некоторые конфигурации в базе данных могут измениться, поэтому они будут вести себя по-разному.

Я мог бы отслеживать все изменения, которые делаю в панели администратора, а затем воспроизводить их в другой среде, но это кажется очень непрактичным.Количество изменений может быть довольно большим, поскольку мы постоянно дорабатываем сайт по своему усмотрению.Кроме того, над этим работают и другие разработчики, и мы даже создали среду для сторонних разработчиков и техническую поддержку от поставщиков расширений Magento.Я не могу уследить за всем, что они делают.

Я видел массу сообщений только об экспорте продукции, так что проблема не в этом.Мне бы хотелось наоборот. Возможно, кто-то составил список всех таблиц, необходимых для клонирования сайта Magento. без продукты и заказы, а также информацию о клиентах. Просто всё, что настраивается в админке.

Кто-нибудь делал это раньше?


ОБНОВЛЯТЬ: Для читателей я отмечаю ответ @mbalparda о файлах ручного развертывания как принятый, пока не появится что-то еще, что будет соответствовать требованиям.Я буду обеспечить соблюдение правил для ведения журналов изменений в панели администратора от всех участвующих разработчиков. поэтому у нас есть один единый список в конце.На самом деле это не ответ на вопрос, но это метод, который я буду использовать для решения этой проблемы, пока не найду лучший процесс.

Это было полезно?

Решение

core_config_data и core_resources — два хороших места для начала.cms_* должен содержать большую часть соответствующей информации о блоках, cms и виджетах.Помимо этих таблиц, большинство таблиц core_* содержат некоторую важную информацию о веб-сайте, который вы используете.

Список далеко не полный.

Еще один хороший вариант — сохранить версию базы данных в GIT и использовать инструмент сравнения, чтобы увидеть, что изменилось между выпусками, но могут возникнуть некоторые проблемы с безопасностью, поскольку личная информация может находиться в репозитории.

Хорошей практикой, которую я часто использую, является наличие файла развертывания вручную, в котором сохраняются все изменения, которые мы сделали в другой среде, и после развертывания кода следующим шагом является проверка файла развертывания вручную, чтобы узнать, нужно ли что-то сделать.Это используется в тех случаях, когда не все изменения могут быть внесены с помощью обновлений sql/данных, это обычный способ внесения изменений sql/данных в Magento.

Следует отметить, что перемещение баз данных между средами не всегда является лучшим выбором, поскольку изменения, которые администратор мог внести на действующий сайт, будут потеряны, если они не будут реплицированы в БД, которую вы используете в другой среде.

Другие советы

База данных Magento не является вашей обычной базой данных. Это большой и сложный.
Перемещение его части из одной среды до другой не является небольшой задачей.

Вот почему я обычно избегаю изменения настроек конфигурации или добавления блоков и / или страниц вручную.

Я позволил клиенту сделать это только на живом сервере.

Что мне нужно сделать, пока я делаю это через сценарии обновления.

Таким образом, все версимо и портативно.
Я знаю, что это рода перетаскивание, чтобы написать сценарий обновления только для удаления режима отображения списка для страниц продукта, но я пока не нашел лучшего способа.

Вот небольшой пример того, как вы можете изменить настройку конфигурации через скрипт обновления.

Следующее включает доставку FlatRate:

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

Я думаю, это может работать, если вы поместите его в сценарий обновления внутри sql/[resource_name_here], но для манипулирования к данным, я использую data/[resource_name_here].

Вот другой скрипт, который добавляет статический блок.

$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();
.

Вы можете в основном сделать это для каждого у вас предела.

Я нашел прекрасный инструмент для экспорта и импорта настроек конфигурации https://github.com/zookal/Harrisstreet-Impex

Это много, что вы, ребята, и я ищу, я думаю, я думаю.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с magento.stackexchange
scroll top