Как я могу синхронизировать данные во время развертывания?

У меня есть возможность создавать веб-сайты на Drupal, используя среды разработки, подготовки и производства. Синхронизация кода между сайтами - простая задача с использованием Subversion. Что не так просто, так это распространение изменений данных базы данных (а не только схемы) между установками.

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

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

Есть ли инструмент, который это сделает? Как вы работаете с одним или несколькими разработчиками в таком проекте?


person ringmaster    schedule 26.11.2008    source источник
comment
См. предыдущие ответы на этот вопрос   -  person Eli    schedule 26.11.2008
comment
возможный дубликат стратегии управления исходным кодом Drupal?   -  person gnat    schedule 16.11.2012


Ответы (4)


Здесь мы в значительной степени отказались от использования CCK для прототипов и v.simple типов узлов. Не стоит пытаться отделить «конфигурацию» от «содержимого» в базе данных. Есть множество способов, которыми вы можете попытаться синхронизировать вещи, но, короче говоря, если это не находится в файле или не дает вам возможность экспортировать в один, вам будет больно. (В качестве дополнительного бонуса экспорт ваших представлений в файл будет немного быстрее, чем извлечение его из БД каждый раз, когда он используется.)

Вы упоминаете серверы Dev, Staging и Live - если у вас есть разработчики, вносящие недокументированные изменения в Staging, вы облажались. Если вы регулярно синхронизируете Staging с Live и предписываете политику (здравого смысла), что единственные изменения, внесенные в Staging, - это вещи, которые были разработаны в Dev и тестируются перед перемещением в Live, вы можете добиться большего успеха.

person Sean McSomething    schedule 26.11.2008

Для базовой синхронизации данных: я использую mysqldump для выгрузки всех данных в файл .sql каждую ночь. Затем сценарий регистрирует его в системе контроля версий. Это записано в простом сценарии bash, но вы можете сделать что-то подобное практически на любой платформе ...

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

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

person Oli    schedule 26.11.2008
comment
Вы действительно использовали mysqldump для ›постановки› разработки на инсталляции Drupal? Он действительно изо всех сил пытается объединить контент и конфигурацию в базе данных, что делает практически невозможным использование дампов базы данных таким образом ... Если вам вообще удалось это на Drupal, мне было бы интересно, как вы это сделали: ) - person David Gardner; 02.07.2009

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

Я думаю, что здесь хорошая стратегия - использовать 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. Мы широко его используем. Это позволяет нам продвигать новый код, который изменяет конфигурацию базы данных, без необходимости повторно импортировать базу данных или вносить оперативные изменения. Это также означает, что мы можем правильно тестировать выпуски, не опасаясь скрытых изменений в базе данных.

Наконец, 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;
} 
person Stewart Robinson    schedule 06.01.2009

Используйте систему управления версиями базы данных. Для этого вам понадобится таблица VersionInfo в базе данных и все ваши запросы sql ddl и dml в формате xml вместе с информацией о версии. Теперь у вас есть только простой инструмент .net, который будет проверять таблицу VersionInfo и запускать все запросы из xml, которые добавляются после этой версии, и обновлять версию до текущей в versionInfo.

person Ramesh Soni    schedule 26.11.2008