Синхронизация базы данных magento от разработки до производства

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

Обзор

Имея дело с локальной разработкой, которая объединяется с производственной, нужно быть уверенным, что изменения схемы и данных, относящиеся к новым или измененным функциям, также применяются при обновлении файловой системы. Именно так работает Magento. Файлы конфигурации модуля могут содержать номер версии и могут настраивать ресурсы установки. Эта информация используется для входа в рабочий процесс изменения схемы и данных, в результате чего информация о версии добавляется в базу данных. Именно согласованность между номером версии, обозначенным файлом, и номером версии, зарегистрированной в базе данных, позволяет / системе может сделать вывод о том, что база данных находится в соответствующем состоянии с учетом имеющихся файлов.

Это означает, что когда новые / обновленные файлы модулей объединяются в производственную среду и выполняются необходимые условия (например, кеш конфигурации недействителен и т. Д.), Должно произойти обновление базы данных. Ваше (правильное) беспокойство заключается в том, что этот процесс может сломаться из-за различий на уровне удаленных серверов, различий в удаленных данных и т. Д. Без строго регулируемого процесса тестирования интеграции возникают некоторые накладные расходы.

План атаки: выберите правильную стратегию

Основная деятельность в этой области - оценка областей воздействия модуля на базу данных. Это должно быть просто с любым модулем, который стоит установить; проверьте любое из следующего:

1. Файл system.xml
2. Наличие скриптов установки / обновления в папках sql или data
3. Наличие настраиваемого класса ресурсов установки (настроенного в global/resources xpath)
4. Соответствующий XML-файл конфигурации (номер версии в узле конфигурации модуля и ресурс настройки в global/resources xpath)

Для 1 просто просмотрите структуру и знайте, что ее влияние на базу данных будет ограничено таблицей core_config_data, и, как правило, только после того, как администратор сохранил значения через графический интерфейс (обратите внимание, что 1. также применяется ниже).

Для 2 и 3 просмотрите сценарии, которые должны быть запущены. Их можно разделить на три основные области: 1. Настройки конфигурации - ищите setConfigData() и deleteConfigData() вызовов 2. Добавление и редактирование таблиц (новые таблицы, добавление столбцов и т. Д.) 3. Изменения и дополнения, связанные с EAV; ищите ресурсы для настройки EAV 4. Изменения данных, отличных от EAV: установка новых данных или изменение существующих данных

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

Обычно вы никогда не захотите отправлять данные, содержащиеся в базе данных, из dev> prod. Определения вашей схемы должны содержаться в сценариях установки Magento sql. Если у вас действительно есть новые данные, которые вы хотите перенести в продукт, вам придется делать это в индивидуальном порядке. Скорее всего, вы перейдете из prod> dev, чтобы проверить данные и конфигурацию, прежде чем запускать реальный случай на prod.

Случай - 1:

Если на вашем производственном сервере есть те же данные (БД), что и на локальном сервере, просто скопируйте базу данных и файлы на производственный сервер и выполните следующие действия:

1) Удаляем содержимое папки / var

2) Измените значения файла /app/etc/local.xml. Здесь вы можете найти данные своей строки подключения (пользователь базы данных, хост и имя).

3) После того, как вы загрузили свою базу данных, вам необходимо внести некоторые изменения.

Запустите этот запрос:

SELECT * FROM core_config_data WHERE path = 'web/unsecure/base_url' OR path = 'web/secure/base_url';

у вас получится 2 ряда. обновить эти строки, выполнив этот запрос

UPDATE core_config_data SET value = 'YOUR_NEW_LIVE_URL' WHERE path LIKE 'web/%/base_url';

Это все.

Случай - 2:

Если вы не хотите изменять данные БД в производственной среде, вам необходимо установить модули через megen, чтобы напрямую подключиться к производственному серверу. И вы можете обновить файлы, которые вы изменили, в Local.