Как люди управляют производством системы управления контентом?

Question

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

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

Итак, наконец, мой вопрос:

Как вы решаете проблемы постановки производства в реальном времени для CMS?

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

Answer 1

Я ответил на вопрос о стратегиях развертывания БД.

Существует также вопрос о развертывании кода.

Там, где я работаю, мы работаем над довольно большим развертыванием Drupal. У нас примерно следующая настройка.

У всех разработчиков есть локальная песочница (Drupal + DB). Код коммита в ветке, которая используется всеми остальными разработчиками (нас около 15). Это включает в себя изменения конфигурации, которые выполняются функциями обновления.

Когда разработчики делают svn up, они также запускают update.php для локального выполнения любых изменений конфигурации.

У нас есть система тестирования спринта, которая работает проще всего и может использоваться для пользовательского тестирования.

В конце спринта (мы используем scrum), мы объединяем ветвь в ствол и запускаем тесты на этом.

Затем мы помечаем это как релиз и разворачиваем его в живую (используя Capistrano), наконец запускаем update.php вживую, чтобы применить изменения конфигурации к живому.

Любые экстренные исправления развертываются из транка, чтобы работать как точка выпуска 7.1 и т. Д.

Если вам нужна дополнительная информация, пожалуйста, оставьте комментарий.

Answer 2

После нескольких недель, потраченных на преодоление кривой обучения в Drupal, проблема «слишком много конфигурации хранится в БД» очень расстраивает, если вы создаете сайт любой сложности.

Посмотрите на работу, которую Development Seed делает для решения этой проблемы. Они возглавляют разработку модулей Context , Features и Spaces , которые работают вместе для хранения данных конфигурации в модулях (вне БД), чтобы может быть версии с кодом.

Answer 3

В настоящее время я использую Drupal. Мне было очень трудно найти, как сообщество решает эту проблему.

Это одна из слабостей Друпала; Это действительно не справляется должным образом с этим вопросом. Особенно трудно разобраться, потому что большая часть конфигурации Drupal находится в базе данных.