Стратегия управления версиями Drupal?

Ответ 1

Я думаю, что хорошая стратегия здесь заключается в использовании API профиля установки. С API профиля установки вы можете делать большинство вещей, которые используют инструменты администратора Drupal. Большинство основных форм просто устанавливают переменные в таблице переменных. Чтобы иметь возможность разумно обновлять содержимое базы данных неконтента, то есть конфигурировать, полезно использовать функции обновления.

На моем сайте у нас есть модуль "ec", который очень мало отличается от того, что файл ec.install содержит функции обновления, например. ec_update_6001()

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

function ec_install() {
  $ret = array();
  $num = 0;
  while (1) {
   $version = 6000 + $num;
   $funcname = 'ec_update_' . $version;
   if (function_exists($funcname)) {
     $ret[] = $funcname();
     $num++;
   } else {
     break;
   }
  }
return $ret;
}

Пример функции обновления или два из нашего фактического файла теперь следуют

// Create editor role and set permissions for comment module
function ec_update_6000() {
  install_include(array('user'));
  $editor_rid = install_add_role('editor');
  install_add_permissions(DRUPAL_ANONYMOUS_RID, array('access comments'));
  install_add_permissions(DRUPAL_AUTHENTICATED_RID, array('access comments', 'post comments', 'post comments without approval'));
  install_add_permissions($editor_rid, array('administer comments', 'administer nodes'));
  return array();
}
// Enable the pirc theme.
function ec_update_6001() {
  install_include(array('system'));
  // TODO: line below is not working due to a bug in Install Profile API. See http://drupal.org/node/316789.
  install_enable_theme('pirc');
  return array();
}

// Add the content types for article and mtblog
function ec_update_6002() {
  install_include(array('node'));
  $props = array(
    'description' => 'Historical Movable Type blog entries',
  );
  install_create_content_type('mtblog', 'MT Blog entry', $props);
  $props = array(
    'description' => 'Article',
  );
install_create_content_type('article', 'Article', $props);
return array();
}

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

Наконец, cck и views поддерживают этот подход. См. Этот фрагмент кода

// Enable CCK modules, add CCK types for Articles in prep for first stage of migration,
// enable body for article, enable migration modules.
function ec_update_6023() {
  $ret = array();
  drupal_install_modules(array('content', 'content_copy', 'text', 'number', 'optionwidgets'));
  install_include(array('content', 'content_copy'));
  install_content_copy_import_from_file(drupal_get_path('module', 'ec') . '/' . 'article.type', 'article');
  $sql = "UPDATE {node_type} SET body_label='Body', has_body=1
  WHERE type = 'article'";
  $ret[] = update_sql($sql);
  return $ret;
} 

Ответ 2

Я написал статью о безболезненном контроле над версиями Drupal с лучшими практиками CVS и Subversion.

К сожалению, по-прежнему существует проблема с источником, контролирующим базу данных, как вы указали. Есть несколько предложенных методов, о которых я упоминаю в дополнительной записи.

Ответ 3

Взятие настроек Drupal из базы данных в код продвигалось вперед в прыжках и границах. Двумя модулями, которые действительно помогают в этой области, являются:

Features - Позволяет собирать объекты, такие как типы контента, таксономия, представления и даже фиды. Мы используем это очень успешно, и это позволило поделиться этими изменениями между разработчиками.

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

Они решают самые большие проблемы с сохранением настройки сайта в базе данных. Однако они не идеальны., мы обнаружили модули, которые не поддерживались или поддерживались некорректно.

Ответ 4

Вы могли бы сэкономить себе часть настройки и работы с SVN, как описано в статье Ника, если вы используете svn: внешняя собственность. Это позволит автоматически обновлять локальную версию Drupal с указанным ветком Drupal, и вы можете использовать точно такой же механизм для своих модулей. Кроме того, поскольку SVN будет читать определения externals из файла, вы можете также установить их под контроль версий!

Я не думаю, что CVS имеет эквивалентную функцию. Однако довольно просто написать простой script, который автоматически установит модуль Drupal, используя только URL-адрес (я сделал это для обновления моего собственного сайта Drupal).

Что касается управления версиями базы данных, это намного сложнее решить. Я бы предложил экспортировать базу данных Drupal "запаса" в файл SQL и поместить ее под контроль версий. У каждого разработчика будет свой собственный локальный сервер базы данных. Затем вы можете предоставить script, который вернет указанную базу данных в вашу версию запаса, содержащуюся в файле SQL.

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

Ответ 5

Некоторые модули, такие как CCK и Views, позволяют экспортировать и импортировать свои данные настройки в виде текста. Вы можете сохранить эти текстовые представления в системе управления версиями.

Ответ 6

К сожалению, здесь просто нет хорошего/простого решения. Проблема заключается в неудачном побочном эффекте архитектуры не только Drupal, но и всех каркасных CMS, где приложения определяются как через конфигурацию (т.е. Данные, хранящиеся в db), так и через исходный код. Ни один из двух вариантов управления данными конфигурации невелик. Во-первых, это то, что вы делаете: определите единый db как канонический (т.е. Производственный db) и попросите разработчиков работать локально с моментальным снимком производственной базы данных и "слить" новую конфигурационную информацию в производственную базу данных через ручную конфигурацию через производственный сайт интерфейс администратора. В случае четко определенных подсистем - т.е. Views - вы могли бы воспользоваться преимуществами функций импорта/экспорта, разработанных для облегчения такой миграции конфигурации. Второй вариант - то есть автоматизация, о которой я думаю, вы ищете - сложно, но может стоить того - или требуется - для крупных проектов с бюджетом для комплексной автоматизации проекта: глубоко погружайтесь в структуру системы/модуля db и разрабатывайте собственные сценарии для объединить новые данные конфигурации на уровне таблицы/записи в производственный дБ, скажем, как часть ночной "сборки" последнего db. Боюсь, что нет никакого промежуточного решения.

Что касается контроля версий для исторического отслеживания данных конфигурации, такой модуль, как backup_migrate, позволяет выполнять автоматические SQL-дампы db. Вы можете выбрать, какие таблицы сбрасывать, определяя резервный "профиль" и можете создать тот, который оставил большой контент, протоколировал и кэшировал таблицы (например, node, cache_content, watchdog) из дампа, чтобы вы остались с более управляемым куском для управления версиями. Некоторые простые сценарии на сервере или в другом месте могут захватить последний дамп и добавить его в ваш репозиторий.

Ответ 7

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

Вы также можете управлять начальной, неэкспортируемой конфигурацией и изменениями конфигурации через профиль центрального контроллера или модуль. Используйте его для включения модуля, создания пользователя и т.д.

См. Разработка → постановка → проблема рабочего процесса в Drupal и Разработка, основанная на кодах: эффективное использование функций в презентациях Drupal 6 и 7.