Развертывание обновлений контента с промежуточного сервера на работающий сервер

8

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

Существуют ли модули, которые могут сделать это и обрабатывать страницы книги?

antgiant
источник
Я думаю, что это в некоторой степени связано с drupal.stackexchange.com/q/137/134 . Вы можете взглянуть на ответ там и посмотреть, поможет ли он, или уточнить ваш вопрос о том, почему он отличается.
Чалки
Ни один из этих ответов не работает для страниц книги и не удаляет их. Оба из которых очень важны для нас. Кроме того, создание полной базы данных и файлового дампа каждый раз кажется серьезным излишним.
antgiant
Можете ли вы установить блокировку контента на производстве, пока вы меняете систему подготовки?
BetaRide

Ответы:

3

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

Расшифруйте
источник
1

Я предполагаю, что Drupal 6 здесь, и лично не знаю, будет ли он работать с модулем книги, но вы смотрели в Deployment ?

вовремя
источник
0

Вы также можете попробовать Phing , с помощью которого вы можете автоматически:

  • Сделайте дамп промежуточной базы данных, используя mysqldump.
  • Скопируйте файл mysqldump с одного сервера на другой, используя шифрование SCP и Public-Private Key.
  • Импортируйте mysqldump из файловой системы в базу данных.
  • Запустите команду Feature Revert All ( drush fra -y), чтобы ваш производственный сервер обнаружил производственные параметры (такие как блоки, представления, контексты и т. Д.), Найденные в коде компонентов.

Проблемы, которые я вижу с этим подходом:

Вам нужно будет выполнить очень точный экспорт базы данных, это означает, что нужно взять только таблицы node, node_revisions, cck и menu.

В этом последнем пункте (ссылки меню), если вы не обращаетесь к серверу stage и prod с использованием одних и тех же псевдонимов URL, у вас будут разные записи пунктов меню, и это будет серьезной проблемой.

любитель бариста
источник
3
Я пытаюсь придерживаться модулей Drupal, если это возможно. И, честно говоря, эта идея выглядит как авария с повреждением данных, ожидающая своего появления.
antgiant
0

Мне действительно нравится метод полного дампа БД, который можно записать в сценарии и который может завершиться всего за несколько секунд. (Сохранение ваших ревизий под контролем и исключение кеш-таблиц и т. Д. Может значительно уменьшить размер.) Вы могли бы даже создать простой модуль, чтобы предоставить издателям контента интерфейс для запуска этого процесса.

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

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

matthewv789
источник