Drupal源代码控制策略?

我认为这里的一个好策略是使用InstallProfileAPI。使用InstallProfileAPI,您可以完成使用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和视图支持这种方法。请参阅此代码段

// 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;
} 

painless Drupal revision control with CVS and Subversion 不久前的最佳实践。

不幸的是,正如您所指出的,仍然存在源代码控制数据库的问题。这里有一些建议的方法,我在一篇文章中提到过 additional post

将Drupal设置从数据库转换成代码已经取得了长足的进步。在这方面真正有帮助的两个模块是:

Features -允许您收集实体,例如内容类型、分类法、视图,甚至提要。我们正在非常成功地使用它,它使得在开发人员之间共享这些更改成为可能。

Strongarm

这些解决了将站点设置保留在数据库中的最大问题。但它们并不完美。我们发现模块不受支持或支持不正确。

如果您使用 svn:externals

我不认为CVS具有同等的特性。然而,编写一个简单的脚本来自动安装Drupal模块非常容易,只需要一个URL(我这样做是为了让自己的Drupal站点保持最新)。

就数据库版本控制而言,这是一个更棘手的问题。我建议将“stock”Drupal数据库导出到SQL文件,并将其置于版本控制之下。每个开发人员都有自己的本地专用数据库服务器可供使用。然后,您可以提供一个脚本,将指定的数据库还原为SQL文件中包含的库存版本。

作为一个如何用其他方法解决这个问题的例子,我将描述工作中的情况。我在一个web应用程序上工作;它不使用数据库,因此不会遇到这些问题。我们绕过站点重复设置的方法是从源代码管理进行重建,并提供一个程序来实现站点的自动部署。该计划也被我们的客户用作他们创建网站的方式。

不幸的是,这里没有一个好的/简单的解决方案。这个问题不仅是Drupal架构的一个不幸的副作用,而且是所有框架类型的CMS架构的一个不幸副作用,在CMS架构中,应用程序通过配置(即数据库中存储的数据)和源代码来定义。管理配置数据的两个选项都不是很好。第一个是您正在做的:将单个数据库定义为规范数据库(即生产数据库),让开发人员在本地使用生产数据库的快照,并通过生产站点管理界面通过手动配置将新配置信息“合并”到生产数据库中。对于定义良好的子系统(即视图),您可能能够利用为简化这种配置迁移而开发的导入/导出功能。第二种选择——即我认为您正在寻找的自动化——对于预算复杂的项目自动化的大型项目来说是困难的,但可能是值得的——或者是必需的:深入研究系统/模块数据库结构,开发定制脚本,将表/记录级别的新配置数据合并到生产数据库中,比如,作为最新数据库每晚“构建”的一部分。恐怕中间没有解决办法。

在配置数据历史跟踪的版本控制方面,类似backup_migrate的模块允许您执行数据库的自动SQL转储。您可以通过定义备份“配置文件”来选择转储哪些表,并可以创建一个将大型内容、日志记录和缓存表(例如节点、缓存内容、监视程序)保留在转储之外的备份“配置文件”,以便为版本控制留下一个更易于管理的块。在服务器或其他地方编写一些简单的脚本可以获取最新的转储并将其添加到您的respository中。

Drupal现在支持 可导出配置 允许您将大部分站点配置移动到代码中。在的帮助下,配置变量、视图、内容类型、字段、输入格式等支持可导出 features

您还可以通过中央服务器管理初始的、不可导出的配置和配置更改 控制器

看见 The Development -> Staging -> Production Workflow Problem in Drupal Code driven development: using Features effectively in Drupal 6 and 7