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

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

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

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

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

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

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

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

EDIT, как и было предложено, некоторые решения были предложены в прошлом, но ни одно из них не дает окончательного решения:

7 голосов | спросил Riccardo 5 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 05 Sep 2016 14:08:26 +0300 2016, 14:08:26

2 ответа


1

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

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

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

ответил montrealist 5 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 05 Sep 2016 15:11:15 +0300 2016, 15:11:15
1

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

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

  

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

ответил marekeiba 10 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 10 Sep 2016 15:44:30 +0300 2016, 15:44:30

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132