Постановка сайтов, как вы управляете синхронизацией обновлений в БД?

Широко признано, что разработчики должны тестировать обновления через промежуточный сайт, прежде чем выпускать их на действующий сервер, однако, как только обновления разработки потребуют изменений в БД Wordpress, все усложняется, так как пользователи на живом сайте тоже будут обновлять БД.

Единственный (запутанный) поток, который я могу себе представить, заключается в следующем:

1. Тест на локальном сервере (WAMP, XAMP и т. Д.)
2. Когда все будет готово к развертыванию, переведите работающий сайт в режим обслуживания.
3. Резервное копирование живого сайта (Duplicator, sqldump и т. Д.)
4. Создайте клон заблокированного живого сайта на промежуточный сайт
5. Загрузка изменений из локальной среды на промежуточный сайт
6. Проверьте место проведения
7. Нажмите постановочный сайт, чтобы жить.
8. Удалить режим обслуживания

Недостатки потока выше:

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

Интересно, есть ли лучший и более автоматизированный способ добиться этого?

Как вы думаете?

РЕДАКТИРОВАТЬ, в соответствии с просьбой, некоторые решения были предложены в прошлом, но ни одно не предлагает окончательного решения:

• 9/2010 - Синхронизация базы данных между dev / staging и production
• 12/2011 - Развертывание обновленных или новых плагинов, которые изменяют таблицу wp_options
• 9/2014 - Как загрузить локальные изменения на действующий сервер без переопределения новых сообщений / страниц?
• 1/2015 - Как поддерживать блоги WordPress сайта в производстве и постановке?

Новые хостинг-провайдеры, которые специально работают с WordPress, обычно имеют инструменты для облегчения этой боли. Я поместил своих клиентов в Pantheon, у которого есть этот аккуратный рабочий процесс с поддержкой Git , где код только перемещается вверх (от разработчика к этапу к производству), а содержимое БД только перемещается вниз (наоборот, из кода). Копирование базы данных из производства в промежуточное состояние осуществляется одним щелчком мыши с помощью их интерфейса. При условии соблюдения этого рабочего процесса это в значительной степени устраняет проблему путаницы в производственной базе данных, позволяя мне всегда тестировать свои изменения на свежем клоне данных производственной базы данных в любой стадии разработки.

Не нужно использовать Pantheon - вы можете использовать подобный подход в своем процессе, используя свои собственные инструменты (Git + плагин для клонирования БД, такой как WP Migrate DB). Я просто считаю, что этот способ хорошо работает для меня.

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

Взгляните на VersionPress, который обеспечивает управление версиями GIT для всего процесса (файлов и базы данных)

Как описано на их сайте:

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