在标准的 PHP 或基于源代码的项目中，我们可以轻松地将所有的代码存储在 SVN 中，每个开发人员可以检出自己的副本并协同工作。
然而，在开发 Drupal 站点时，大部分工作都是“设置”相关的。除了主题和模块外，你并没有真正的“源代码”。那么如何运行多个相同站点的实例，以便开发人员可以同时工作并分享他们的工作呢？
示例场景：
我们发布了一个带有内容类型“X”的 Drupal 站点的初始版本。我们还最初在站点上发布了一个视图，按时间顺序列出所有“X”类型的节点。客户开始使用该站点，添加内容、菜单项等。
下一个版本计划向该视图添加用户搜索功能。然而，该设置包含在数据库中。我们可以将生产数据库复制到开发版本以获取最新数据，同时在更改视图时进行工作。然而，在此期间，客户仍然可以更新站点，使我们的开发数据库不同步。当我们准备将新视图推送到生产环境时，是否有比手动重复设置步骤更简单的方法呢？
我认为在这里采用使用安装配置文件 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;
}
我一段时间前写了一篇关于使用CVS和Subversion进行无痛的Drupal版本控制的最佳实践的文章。
不幸的是，你指出了一个问题，那就是源代码控制数据库。有一些建议的方法，我在另一篇文章中提到了。
很遗憾，这里没有一个好的/简单的解决方案。问题是不幸的副作用，不仅是Drupal，而且所有框架类型CMS的架构问题，应用程序通过配置（即存储在数据库中的数据）和源代码来定义。管理配置数据的两个选项都不是很好。第一个选项是您正在执行的操作：将单个数据库定义为规范（即生产数据库），并让开发人员使用生产数据库的快照在本地工作，并通过生产站点管理界面手动配置“合并”新的配置信息到生产数据库中。对于定义良好的子系统-即视图-您可能可以利用导入/导出功能来简化此类配置迁移。第二个选项-即我认为您正在寻找的自动化-很困难，但对于预算充足的复杂项目自动化可能值得或必需：深入了解系统/模块数据库结构，并开发自定义脚本以在表/记录级别将新的配置数据合并到生产数据库中，例如作为最新数据库的每夜“构建”的一部分。恐怕没有任何中间解决方案。
关于历史跟踪配置数据的版本控制，像 backup_migrate 这样的模块允许您执行数据库的自动 SQL 转储。您可以通过定义备份“配置文件”来选择要转储的表，并且可以创建一个将大型内容、日志和缓存表（例如节点、cache_content、watchdog）排除在转储之外的备份配置文件，以便您留下更易管理的版本。服务器或其他地方的一些简单脚本可以获取最新的转储并将其添加到您的代码库中。Drupal现在支持可导出配置，允许您将大部分站点配置移动到代码中。通过features模块，支持配置变量、视图、内容类型、字段、输入格式等导出。
您还可以通过一个中央控制器配置文件或模块来管理初始的、不可导出的配置和配置更改。使用它来启用模块、创建用户等。