Синхронизация базы данных между dev / staging и production

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

Скажем, у меня есть живой сайт WordPress. Я взял свалку всего, копируя ее в нашей среде разработчиков. Я начал делать изменения. Через 1 неделю я готов развернуть свои обновления. Тем временем база данных на производственном участке изменилась (новые сообщения, новые комментарии и т. Д.). Как синхронизировать изменения между производством и разработкой во время развертывания и возможно ли автоматизировать (по крайней мере) этот процесс?

34 голоса | спросил Alex 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 22 Sep 2010 17:18:30 +0400 2010, 17:18:30

4 ответа


9

Там может быть лучший способ, который мне не хватает, но я дам вам 2 варианта:

1.Use XML Export для экспорта новых сообщений и комментариев. Затем используйте WordPress Importer , чтобы импортировать новые сообщения и комментарии в базу данных dev

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

  

Тем временем производство изменилось (новые сообщения, новые комментарии и т. д.)

Это решит вашу проблему с введением любого измененного содержимого.

2. Используйте команду INSERT IGNORE INTO MySql, чтобы добавить новые таблицы из dev. или REPLACE , чтобы перезаписать повторяющиеся строки в одной таблице.

Прежде чем использовать MySql, сделайте резервную копию обеих баз данных и переместите базу данных gz на рабочий сервер и загрузите дамп (измените имя dev, если оно совпадает с производством.

  INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
ВЫБРАТЬ *
FROM `_wp_dev_db`.`wp_cool_plugin_options`
 

Мне не нравятся команды MySql, поэтому я бы пошел с вариантом 1.

ответил Chris_O 23 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 23 Sep 2010 05:45:31 +0400 2010, 05:45:31
2

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

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

ответил curtismchale 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 22 Sep 2010 18:21:33 +0400 2010, 18:21:33
1

Как только вы коснетесь темы параллельных изменений, вы касаетесь области управления конфигурацией. С большим количеством шаблонов, собственных сообществ (http://www.cmcrossroads.com/) и инструментов не столько для управления версиями (как svn /git), но и для поддержки управления конфигурациями (шаблонов), таких как clearcase. (совершенно разные области).

В этом случае это все еще простая ситуация, и вы обнаружите, что она будет работать с некоторыми ограничениями и некоторыми ручными работами и некоторыми списками.

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

Если вы хотите сделать это немного более профессионально:

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

b) описывают рабочие процессы, которые могут произойти, например. что происходит с исправлением, что происходит с чем-то новым развитием, в каком случае вы меняете контент на своей стороне, что называется, и кто это делает, кто является его владельцем, например? новый пост или новый плагин.

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

d) для каждого из типов CI под (a) записывает разрешение. Например. для ВСЕГО - это текст (или экспортированный текст, например, файлы php, но ТАКЖЕ простой текст в файлах XML). Это действительно не проблема, но вам нужен хороший инструмент слияния. например С помощью ClearCase вы получите три способа слить следующие ситуации:  1) тривиальные слияния: он будет делать это автоматически  2) нетривиальная автоматическая: она будет делать это автоматически, НО вам нужно ее проверить  3) нетривиальный неавтоматический: это конфликт, например. на 1 строке сделано несколько изменений. Не тривиальными являются минимальная часть, которую вам нужно заботиться вручную, хороший инструмент для слияния приведет вас в этом, например, (в котором также происходит слияние слов и где вы можете ссылаться на другие коммерческие или некоммерческие слияния для определенных типов файлов). Furtermore, если вы определили в (a) файлы, которые должны быть скопированы, - только тогда их поведение будет не сливаться, а просто скопировано в одностороннем порядке, переписывая другую версию без слияния (например, плагины, которые вы не изменили). Многие из этих типов возможны с различным поведением. Но запишите отношения между CI,

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

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

Если теперь вы можете управлять этими потоками под вашими установками WordPress и синхронизировать их с содержимым базы данных и т. д., тогда вы можете выполнять слияния в средстве CM /версии, а затем экспортировать его обратно в другая среда.

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

Технически почти всегда все возможно проверить http://www.cmcrossroads.com/forums для сценария которые в десятки или сотни раз более сложны, хотя всегда используют один и тот же подход и используют один и тот же набор шаблонов CM.

: поставьте под ним слой управления версиями, автоматизируйте слияния и обработайте конфликты, а затем импортируйте в целевую среду. Придумайте стратегию потока, которая подходит здесь и записывает ее. Выполните небольшое управление CM CM. Это было бы профессиональным решением, в противном случае установить некоторую копию db-копии, скрипты и т. Д.

ответил edelwater 15 12010vEurope/Moscow11bEurope/MoscowMon, 15 Nov 2010 00:55:50 +0300 2010, 00:55:50
1

Я только что опубликовал сообщение о том, как синхронизировать производственные данные с нашей постановкой, просмотрите мой пост в блоге об этом: http://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite- базы данных из-производства к постановке-enviorment /

Если вы хотите синхронизировать код и другие вещи, я бы рекомендовал создать git или mercurial репозиторий с соответствующим файлом игнорирования.

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

ответил Niklas 6 Jam1000000amFri, 06 Jan 2012 03:21:21 +040012 2012, 03:21:21

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132