it-swarm.com.ru

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

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

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

34
Alex

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

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

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

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

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

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

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

INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
SELECT *
FROM `_wp_dev_db`.`wp_cool_plugin_options`

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

9
Chris_O

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

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

2
curtismchale

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

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

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

1
Niklas

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1
edelwater