alex
  • 0
Учитель

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

  • 0

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

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

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

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

    Лучше всего импортировать в 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • 0

Оставить ответ

You must login to add an answer.