Как я могу синхронизировать данные во время развертывания?
У меня есть возможность создавать веб-сайты Drupal с использованием сред разработки, организации и производства. Синхронизация кода между сайтами - простая задача с использованием Subversion. Что не так просто, так это распространение изменений в данных базы данных (не только в схеме) между установками.
Причина этого будет знакома любому разработчику Drupal. Drupal хранит определенные параметры конфигурации в базе данных, в частности, связанные с полями CCK, представлениями и другими модулями, которые позволяют динамически настраивать объекты с помощью интерфейса администратора. Недостаточно просто синхронизировать схему - важная информация также содержится в данных.
То, что я ищу, - это способ синхронизации этих изменений базы данных, так что если один разработчик вносит изменения в поле CCK на промежуточном сервере, они могут быть переданы в локальные среды разработки для дополнительной работы и, в конечном итоге, в производственную среду.
Есть ли инструмент, который сделает это? Каков ваш процесс работы с одним или несколькими разработчиками в таком проекте?
4 ответа
Здесь мы в значительной степени отодвинули CCK для использования для прототипов и типов узлов v.simple. Не стоит головной боли пытаться отделить "конфигурацию" от "контента" в базе данных. Существуют всевозможные способы, с помощью которых вы можете попытаться синхронизировать данные, но, короче говоря, если вы не в файле или не можете экспортировать в один файл, вам будет больно. (В качестве дополнительного бонуса экспорт ваших представлений в файл будет происходить немного быстрее, чем извлекать его из БД при каждом его использовании.)
Вы упомянули серверы Dev, Staging & Live - если у вас есть разработчики, делающие недокументированные изменения в Staging, вы облажались. Если вы регулярно синхронизируете Staging с Live и применяете политику (здравого смысла), согласно которой единственными изменениями, внесенными в Staging, являются те вещи, которые были разработаны в Dev и тестируются до перехода в Live, вы можете добиться большего успеха.
Для синхронизации основных данных: я использую mysqldump, чтобы выгрузить все данные в файл.sql на ночной основе. Затем сценарий возвращает его в систему контроля версий. Это реализовано в простом скрипте bash, но вы можете сделать что-то похожее практически на любой платформе...
Я только что прочитал немного дальше, и я не уверен, поможет ли мой метод. Мне никогда не приходилось объединять дамп SQL, поэтому я не могу комментировать, насколько эффективно он управляется.
Несмотря на то, что вы должны быть в состоянии отправить изменения (схему, новые данные) на промежуточный / рабочий сервер, у вас может быть больше хлопот, тянущих изменения обратно в dev. Как я говорю - объединение может или не может быть возможным. Я просто не знаю.
Я попытался ответить, как я делаю это в другом вопросе. Я также выложу здесь
Я думаю, что хорошей стратегией здесь является использование 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;
}
Используйте систему управления версиями базы данных. Для этого вам понадобится таблица VersionInfo в базе данных и все ваши запросы sql ddl и dml в формате xml вместе с информацией о версии. Теперь у вас есть только простой инструмент.net, который будет проверять таблицу VersionInfo и запускать все запросы из xml, которые добавляются после этой версии, и обновлять версию до текущей в versionInfo.