Синхронизация базы данных WordPress между Dev и Prod

Ранее задавался вопрос о том, как синхронизировать файлы и базу данных между двумя установками Wordpress.

Для уровня базы данных ответ обычно состоит в том, чтобы в основном сбросить одну базу данных и вставить ее на другой сервер. Проблема в том, что вы теряете любые изменения, которые могли быть внесены на сервере prod. Например, показатели использования, комментарии и т. Д.

Имея это в виду, я начинал задаваться вопросом, можно ли будет расширить ORM в Wordpress, чтобы вы могли генерировать дельты и затем вводить их в сайт prod.

Кто-нибудь пробовал это, изучал или у вас есть идеи или комментарии?

Реальность такова, что мы хотим, чтобы это было: http://www.liquibase.org/

Liquibase - это библиотека с открытым исходным кодом (Apache 2.0 Licensed), независимая от базы данных, для отслеживания, управления и применения изменений в базе данных. Он основан на простом предположении: все изменения в базе данных хранятся в удобочитаемой, но отслеживаемой форме и проверяются в системе контроля версий.

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

Однако мы можем подражать некоторым из них - используя некоторые из инструментов, перечисленных на этой странице:

/programming//q/225772/149060

Например, жидкая база имеет отличительную особенность, которая также, необязательно, включает изменения в данных. Мы могли бы потенциально вывести схему и разность данных в сценарий, исключив (насколько это возможно) определенные таблицы, которые могут включать тестовые данные (например, опубликовать и т. Д.), А затем применить сценарий к производственной базе данных.

MySQLDiff (обсуждаемый в вопросе StackOverflow) выполняет различие схемы, и его автор рекомендует mysql_coldiff для различий в табличных данных - оба они реализованы в perl, если инструменты java (liquidbase) слишком загружены для ваших серверов - хотя обе базы данных локальны и запуск инструмента на вашем ПК решает эту проблему ...

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

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

Если мы посмотрим на код инструментального крюка @bueltge, то плагин вызывает плагин для вдохновения: https://gist.github.com/1000143 (спасибо Рону Реннику через G + за указание мне в направлении SAVEQUERIES и крюку отключения, что ведите меня, чтобы найти его)

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

Например:

Имя захвата: активировать и настроить плагин XYZ

Переключение состояния захвата - на

... установить и настроить плагин XYZ

Переключение состояния захвата - выкл.

Экспорт сценария миграции для: активировать и настроить плагин XYZ

Нажмите кнопку «Экспорт» - чтобы создать всплывающее текстовое поле с отфильтрованным захваченным SQL-кодом - в идеале предварительно отформатированный как сценарий оболочки с вызовом mysql из командной строки. Скопируйте и вставьте его в папку с кодом миграции и добавьте в хранилище исходного кода.

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

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

Я уже влюблен.

Кто-нибудь еще?

База данных синхронизации WordPress плагин делает большую работу по синхронизации данных между двумя серверами.

По умолчанию он перезаписывает ВСЕ данные назначения, однако я только что добавил некоторые улучшения в плагин, которые позволяют синхронизировать только определенные таблицы базы данных. Это может помочь вам сохранить комментарии, пользователей и другие данные, которые вы не хотите перезаписывать. Это дает вам гранулярность, которая вам нужна?

Я еще не опубликовал свои изменения для широкой публики, но если вы заинтересованы в копии, отправьте мне электронное письмо на simon-at-yump.com.au. Если кто-то посчитает это полезным или у него есть дополнительные запросы, дайте мне знать, и я посмотрю, что я могу сделать.

ОБНОВЛЕНИЕ: Я также только что нашел плагин WP-Sync-DB , который является вилкой коммерческого плагина WP-Migrate-DB-Pro . Это делает очень похожую вещь, хотя, вероятно, имеет больше полировки, чем синхронизация базы данных .

Специально для этой задачи существует относительно новый коммерческий сервис. Это называется RAMP:

http://alexking.org/blog/2011/07/20/ramp-content-deploy-wordpress