Как объединить изменения из рабочей копии сайта в действующий сайт без потери нового контента?

40

Какова наилучшая процедура для объединения работ, выполненных с версией разработки сайта, в рабочую копию? Часто на сайт добавлялось много нового контента с тех пор, как началась разработка новейших функций. И большинство дополнений к сайту будет связано с изменениями базы данных. Так что копировать любые новые файлы легко, но как насчет базы данных? Как объединить изменения с существующей производственной базой данных, не теряя новый контент, который был добавлен с момента последнего обновления рабочего сайта? Есть ли модули, которые помогают с этим?

database updating Chaulky
источник
2
Устранить путаницу: объединить и перенести - это два разных слова. Вы использовали оба в своем вопросе. Если живой сайт пуст, вам нужно перенести копию разработки на живой сайт / хост. Если у живого сайта уже есть контент, необходимо объединить новое содержимое из рабочей копии с живым сайтом (объединение довольно сложно). Что нужно сделать?
user931

Ответы:

16

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

Для миграции контента есть много вариантов, но нет единого твердого решения. Одним из примеров является пакет развертывания .

будда
источник
пакет Demployment определенно выглядит интересно, хотя он все еще в Dev (даже пока не в бета-версии). Вы использовали это сами? Вы знаете что-нибудь, что бы оно не охватило?
Чолки
2

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

1) Разверните, удалив производственную базу данных и импортировав mysqldump из базы данных разработки. По желанию, запустите regex find / replace заранее для любых жестко закодированных абсолютных ссылок, которые ссылаются на URL-адрес dev в дампе SQL. После импорта базы данных dev в prod, автоматически запускайте операторы SQL (обычно через скрипт), чтобы изменить любые параметры, отличные для prod, чем dev (например, возможно, в таблице переменных есть некоторые параметры подключения для подключения к внешним системам, которые вам нужны изменить, чтобы указать на внешние системы prod вместо версии dev).

2) Используйте модуль Features , как упомянуто budda, для настроек администратора, и используйте модуль Node Export для экспорта / импорта контента в сочетании с модулем Delete All . Итак, рабочий процесс:

  1. использовать node_export и функции для экспорта узлов / функций в файлы
  2. Опционально (и надеюсь) контроль версий
  3. Загрузка файлов в систему Prod
  4. Используйте интерфейс drush или admin для загрузки функций
  5. Используйте drush delete-all или интерфейс администратора, чтобы удалить все узлы типов, которые вы хотите импортировать
  6. Используйте drush ne-import или интерфейс администратора для импорта узлов из файла узлов, который вы экспортировали.

Одно замечание: я бы настоятельно рекомендовал принять стандартный рабочий процесс, в котором контент идет только в одном направлении. Либо Dev -> Prod, либо Prod -> Dev (я предпочитаю этот).

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

coderintherye
источник
В варианте 1, как вы воссоздаете контент, который был добавлен на живой сайт, которого нет на сайте разработчиков? Кажется, что вы перезаписываете все это с помощью dev db, а затем, возможно, меняете некоторые настройки / переменные. Кроме того, какую школу мысли вы используете на своих сайтах в настоящее время? Есть ли плюсы и минусы каждого подхода?
Чалки
В варианте 1 мы теперь используем node_export для регулярной отправки контента (удалив предыдущий контент). Мы привыкли вносить изменения как в dev, так и в prod. Это на самом деле распространенный сценарий в нескольких местах, которые я видел, хотя, очевидно, не идеальный. Вот почему я добавляю, принимаю направление и придерживаюсь его, либо контент идет dev -> prod или prod -> dev, но стараюсь не делать того и другого. И да, мы в основном перезаписываем, хотя больше похожи на стирание и перестройку. На моей новой работе мы выполняем # 2, на моей старой работе мы выполняли # 1, но переходим на # 2 (я все еще консультируюсь с ними).
coderintherye
1

Дамп базы данных действующей копии сайта и его разработки в файле SQL (используйте одинаковые параметры и настройки для обоих дампов).
Затем сравните оба файла SQL, используя небольшой инструмент сравнения ExamDiff . Он будет отображать различия файлов рядом с разными цветами. Вы также можете напрямую перейти к различиям (без прокрутки). Изучите различия и добавьте / отредактируйте строки в файл SQL живого сайта. Убедитесь, что в этом файле нет абсолютного пути / URL-адреса среды разработки. Это сделано! Время восстановить базу данных для живого сайта.
Сделай свою жизнь проще:На первом шаге дамп только тех таблиц, которые изменены. Например, если вы редактировали модуль в копии для разработки, предназначенный для отдельной таблицы, дамп только этой таблицы. Если вы не уверены в конкретной таблице, весь дамп базы данных подойдет.

user931
источник
Эта техника имеет серьезные ограничения в некоторых важных обстоятельствах. Например, если на сайте разработки появились новые узлы, обе ваши базы данных будут содержать записи с одинаковыми идентификаторами узлов, и будет невозможно разрешить ссылки и объединить их из текстового дампа базы данных sql. Такого рода операции лучше выполнять с помощью функций и развертывания, как упоминалось в других ответах.
greg_1_anderson