Как развернуть большой сайт CMS

Question

Я управляю сайтом с помощью PHP cms.
Сайт действительно большой (250 страниц) и критический.
Всегда есть 6 переводчиков и редакторов контента, работающих на сайте параллельно.
До сегодняшнего дня CMS работала так, как если бы у меня не было много изменений для развертывания.

Теперь мы хотим чаще всего запускать и обновлять темы сайта, добавлять области контента, добавлять дополнительные модули в CMS.

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

Во время разработки контент будет изменен.
В 95% случаев модернизация cms будет связана с базой данных и данными изменить.
Итак, как я могу обновить версию сайта/данные/метаданные без потери или повреждения работы, которая была проделана на месте во время разработки

(У нас есть сервер разработки и постановка сервер со своими собственными базами данных , с подрывной деятельностью)

Это не имеет значения, я использую Concrete5.

Благодаря

Update 1
Давайте просто предположим, что у меня есть поле в моем сайте по имени PAGE_TITLE, и я хочу, чтобы изменить имя page_description.
Изменение фактически происходит в базе данных содержание и не в структуре базы данных.
Так что я могу изменить это в среде dev, но у меня нет возможности развернуть это для производства.
Во-первых, потому что я понятия не имею, где происходят изменения на базе перекрестной базы данных.
Во-вторых, даже если у меня есть сценарий, который изменит его в базе данных, почти невозможно отследить эти изменения и добавить его в скрипт.

Answer 1

Две рекомендации:

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

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

Answer 2

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

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

Чтобы сэкономить много проблем, я бы порекомендовал вам потратить время, чтобы отметить все запущенные программы и версии перед созданием зеркала.

В качестве альтернативы вы можете создать субдомен на сервере и загрузить дубликат сайта в этот домен. Обязательно используйте тень базы данных в этом случае!

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

Answer 3

Я еще не нашел систему управления версиями, которая обрабатывала базы данных до моего удовлетворения, хотя RedGate имеет некоторые продукты для управления версиями SQL, на которые стоит обратить внимание. То, что мне всегда приходилось делать при структурных изменениях в производственной базе данных, - это написать скрипт SQL, который вносит необходимые изменения при сохранении существующих данных, и, естественно, протестировать сценарии обновления на dev-сервере, если они вообще есть сложный.