Wordpress и управление версиями

Мы являемся компанией по разработке программного обеспечения и используем Wordpress для статической части веб-сайта. Естественно, весь наш рабочий процесс построен на управлении версиями: несколько разработчиков → непрерывная интеграция → развертывание → развертывание.

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

Мне интересно, что люди делают в подобных ситуациях? Я хотел бы найти способ интегрировать WP в рабочий процесс разработки, а не наоборот: -)

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

Ответ 1

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

В любом случае на веб-сайте StackOverflow есть некоторые связанные вопросы ответы WordPress:

UPDATE

В соответствии с разъяснением это, вероятно, также будет полезно:

Есть ли способ подготовить ревизию опубликованной страницы или сообщения? Какие обходные методы вы использовали?

Надеюсь, что это поможет.

-Mike

Ответ 2

Я просто попал в ту же проблему. Пока мы используем файлы дампа MySQL для экспорта/импорта содержимого базы данных, но он становится уродливым с несколькими людьми, работающими над изменениями базы данных.

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

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

Звучит уродливо, я знаю. Но я подумал об этом некоторое время и пока не вижу элегантного решения.

Ответ 3

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