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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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