Миграция происходит из локальной среды в производственную среду. Производственная среда работает некоторое время и создала много статей.
Чтобы добавить новые вещи на свой сайт, я добавил собственную тему и установил CCK, Views и другие модули в своей локальной тестовой среде. Теперь, когда локальная тестовая среда закончена, как мне перенести ее в производственную среду, не уничтожая содержимое ее базы данных?
Это нетривиальная проблема, на которую почти у всех есть разные ответы: не существует канонического способа работы с Drupal для подготовки к рабочим скачкам. Dries Buytaert, парень, управляющий шоу Drupal, сделал его одной из ключевых инициатив Drupal 8 . Конечно, Drupal 7 был только что выпущен, так что пройдет немало времени, прежде чем он принесет какие-либо плоды.
Проблема может быть разбита на две отдельные проблемы:
Первый может в основном обрабатываться модулем « Функции », который примет конфигурацию вашего сайта и превратит ее в модуль, который вы можете добавить к вашей установке Drupal: таким образом, вы можете добавить его в свою систему контроля версий, не беспокоясь об этом. сдулся, когда вы переносите свой контент.
Последнее действительно сложно, потому что на активном сайте, скорее всего, контент изменится в рабочей среде даже после того, как вы сделали первоначальную синхронизацию со своей средой разработки. Это предотвращает оптовую замену контента во время постановки, как вы можете сделать с конфигурацией.
Кроме того, Drupal не использует универсально уникальные идентификаторы (UUID) для контента: каждый раз, когда добавляется узел или пользователь, идентификатор увеличивается на единицу. Таким образом, то, что может быть узлом 45 на вашем сайте разработки, может быть узлом 90 на вашем рабочем сайте.
К сожалению, у меня нет отличного решения для этого: постановка контента - реальная слабость Drupal. Что я лично делаю, так это добавляю контент только на сайт производства. Если клиент хочет увидеть, как контент выглядит до его запуска, я настрою клон рабочего сайта, доступный только клиенту. Затем, после утверждения, те же изменения вносятся непосредственно в производство.
Есть еще одна альтернатива: модуль Deploy . Предполагается использовать Сервисы, чтобы сделать постановку контента относительно безболезненной. Но я не могу ручаться за его эффективность, и у него нет версии для Drupal 7.
В нашем процессе.
Мы используем Hudson, чтобы перестроить ветки dev / staging для синхронизации веток live и dev.
Поскольку мы используем Git, каждая задача, которую мы выполняем, имеет свою собственную ветвь, а затем, когда она передается в QA, мы объединяем ее в качестве нашего промежуточного сервера для регрессионного тестирования.
Когда мастер готов, мы делаем тестовый выпуск нашего,
Release Serverкоторый является точной копией live (конфигурация, оборудование и т. Д.).Мы используем
Featureмодуль для развертывания конфигураций. Некоторые вещи еще не поддерживаются этой функцией, поэтому мы используем hook_update_N, затем запускаем updatedb.php илиdrush -vd updbdrush fra --yes), чтобы отменить все переопределенные функции.Поскольку мы используем Boost (переход на Varnish) и Memcache, нам нужно очистить кеш (
drush cc all).Мы используем rsync для синхронизации наших изображений / видео и т.д ...
источник
Чтобы перейти с сервера XAMPP на другой сервер, я следовал инструкциям на этом сайте .
Убедитесь, что вы сохраняете ту же структуру на своем рабочем сервере, что и на своем сервере разработки. Мне также пришлось отредактировать некоторые файлы в панели администратора Drupal, расположенной по адресу: admin / config / media / file-system
Убедитесь, что в пути к вашей публичной файловой системе и временном каталоге указаны правильные местоположения.
источник