Я погружался в технологии веб-разработки для удовольствия (да, я должен больше выйти), и я немного шокирован отсутствием четкой поддержки постановки продукции (например, разработки, тестирования, производительности и производственных условий). На самом деле поддержка – это не слово; Системы управления контентом, похоже, активно работают против усилий по обеспечению чистой постановки.
В настоящее время я использую Drupal. Мне очень трудно найти, как сообщество решает эту проблему. Большинство сообщений, которые я видел, рекомендуют воспроизвести шаги, выполненные в разработке на производственной системе (чтение этого на самом деле немного сократило мою жизнь). Я также слышу о том, чтобы вернуть производственные данные разработчикам, чтобы они могли добавлять дополнительные функции. Этого не может быть, что делать, если клиент не хочет, чтобы вы вернули свои данные в среду разработки?
Итак, наконец, мой вопрос:
Как вы управляете вопросами постановки вопросов в реальном мире для CMS?
Я исхожу из того места, где стремление к производству ощущается как отправка людей на Луну, поэтому мне, возможно, придется немного расслабиться. Тем не менее, я по-прежнему интересуюсь ответами, которые связаны с контролем источника, возможностью отката продукции и тестирования.
Я ответил на вопрос о стратегиях развертывания БД.
Существует также вопрос о развертывании кода.
Где я работаю, мы работаем над довольно большим развертыванием Drupal. У нас примерно следующая настройка.
У всех разработчиков есть локальная песочница (Drupal + DB). Код фиксации для ветви, которая распределяется между всеми другими разработчиками (нас около 15). Это включает изменения конфигурации, которые выполняются функциями обновления.
Когда разработчики делают svn up, они также запускают update.php для локального изменения конфигурации.
У нас есть система тестирования спринта, которая работает просто и может использоваться для тестирования пользователей.
В конце спринта (мы используем scrum) мы объединяем ветку в туловище и запускаем тесты на этом.
Затем мы помещаем это как выпуск и развертываем его, чтобы жить (используя Capistrano), и, наконец, запускаем update.php в live, чтобы применить изменения конфигурации для жизни.
Любые аварийные исправления будут развернуты из магистрали, чтобы жить как точка-релиз 7.1 и т. Д.
Если вы хотите получить более подробную информацию, пожалуйста, оставьте комментарий.
После того как вы потратили несколько недель на изучение кривой обучения Drupal, «слишком большая конфигурация хранится в БД» проблема очень сбивает с толку, если вы строите сайт любой сложности.
Взгляните на работу, которую Development Seed делает для решения этой проблемы. Они возглавляют разработку модулей Context , Features и Spaces, которые работают вместе для хранения данных конфигурации в модулях (вне БД), чтобы их можно было версировать с помощью кода.
В настоящее время я использую Drupal. Мне очень трудно найти, как сообщество решает эту проблему.
Это одна из недостатков Drupal; Это действительно не имеет отношения к этому вопросу. Особенно сложно разобраться, потому что большая часть конфигурации Drupal находится в базе данных.