Промежуточные сайты, как вы управляете синхронизацией обновлений в БД?
В целом принято, что разработчики должны тестировать обновления через промежуточный сайт, прежде чем выпустить их на живой сервер, однако после того, как обновления для разработки потребуют изменений в Wordpress DB, все усложняется, так как пользователи на реальном сайте также будут обновлять БД .
Единственный (путаный) поток, который я могу себе представить, следующий:
- Тестирование на локальном сервере (WAMP, XAMP и т. д.)
- После того, как вы готовы к развертыванию, поместите живой сайт в режим обслуживания
- Резервное копирование в реальном времени (Дубликатор, sqldump и т. д.)
- Создайте клон заблокированного живого сайта на промежуточном сайте
- Загрузка изменений из локальной среды на промежуточный сайт
- Проверка промежуточного узла
- Нажмите, чтобы перейти к промежуточному сайту.
- Удалить режим обслуживания
Недостатки потока выше:
- время простоя может быть больше, чем ожидалось для пользователей, в то время как разработчик тщательно тестирует обновления на промежуточном сайте;
- может потребоваться ручное управление модификациями: например, макеты компоновщика сайта siteorigin хранятся в db, поэтому после изменения макета его необходимо импортировать вручную на промежуточном сайте; в этом случае он может быть достаточным, чтобы просто упасть & импортировать страницы на промежуточном сайте и, если они работают, импортировать их на веб-сайте
Интересно, есть ли лучший и более автоматический способ достижения этого.
Как вы думаете?
EDIT, как и было предложено, некоторые решения были предложены в прошлом, но ни одно из них не дает окончательного решения:
- 9/2010 - Синхронизация базы данных между dev /staging и production
- 12/2011 - Развертывание Обновленные или новые плагины, которые изменяют таблицу wp_options
- 9/2014 - Как загрузить локальные изменения на живой сервер без переопределения новых сообщений /страниц?
- 1/2015 - Как поддерживать блоги блога Wordpress в производстве и постановке?
2 ответа
Новые хостинг-провайдеры, специально предназначенные для WordPress, обычно имеют инструменты для облегчения этой боли. Я положил своих клиентов на Pantheon, у которого есть аккуратный рабочий процесс с поддержкой Git , где код только перемещается вверх (от разработчика до постановки на производство), а материал базы данных только перемещается вниз (наоборот, из кода). Копирование базы данных с производства на стадию - это один клик с их интерфейсом. Если этот рабочий процесс соблюдается, это в значительной степени устраняет проблему когда-либо испортить производственную базу данных, позволяя мне всегда проверять мои изменения на свежий клон данных БД на этапе разработки на стадии разработки.
Не нужно использовать Pantheon - вы можете использовать аналогичный подход в своем процессе, используя свои собственные инструменты (Git + плагин клонирования DB, такой как WP Migrate DB). Я просто нахожу, что это хорошо работает для меня.
Вопрос: почему вы поставили свой производственный сайт в режим обслуживания во время тестирования? В большинстве случаев не должно быть необходимости. Единственный случай, о котором я могу думать, - это иметь очень хрупкую систему, очень чувствительную к добавлению в нее дополнительных пользовательских данных, с катастрофической ошибкой для загрузки, но это, вероятно, будет показателем другой, более крупной проблемы, где нужно было бы чтобы переосмыслить всю архитектуру своего продукта.
Посмотрите VersionPress , который приносит GIT-версию для всего процесса (файлы и базу данных)
Как описано на их сайте:
VersionPress обеспечивает безболезненную постановку . Это означает, что вы можете легко создать безопасную среду тестирования для ваших изменений и только объединить их когда они будут готовы. Слияние - ключевое слово здесь - VersionPress обрабатывает ситуации, когда ваш сайт в реальном времени имел новый контент в тем временем плавно.