Question

在标准的基于php或源代码的项目中，我们可以轻松地将所有代码保存在SVN中，并且每个开发人员都可以签出自己的副本并在相同的代码上进行协作。

然而，在开发Drupal站点时，大部分工作都在“设置”中。除了主题和模块，你没有任何“源代码”。如何运行同一站点的多个实例，以便开发人员可以同时工作并分享他们的工作？

示例场景：

我们启动了一个创建内容类型为“X”的Drupal站点的初始版本。我们最初还在网站上启动了一个视图，该视图按时间顺序列出了“X”类型的所有节点。客户端开始使用网站，添加内容，菜单项等。

下一个版本计划将用户搜索功能添加到该视图。但是，它的设置包含在数据库中。我们可以将生产数据库复制到我们的开发版本，以便在我们处理更改视图时获取最新数据。但在此期间，客户端仍然可以更新站点，使我们的开发数据库不同步。当我们准备将新视图推向生产时，除了手动重复在生产安装上设置它的步骤之外，还有更简单的方法吗？

Answer 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代码的版本控制问题。我们广泛使用它。它允许我们推广更改数据库配置的新代码，而无需重新导入数据库或进行实时更改。这也意味着我们可以正确测试版本，而不必担心隐藏的数据库更改。

最后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;
}

Answer 2

我刚才写了一篇关于painless Drupal revision control with CVS and Subversion最佳做法的文章。

不幸的是，正如您所指出的那样，仍有源控制数据库的问题。我在additional post中提到了一些建议的方法。

Answer 3

将数据库中的Drupal设置转换为代码一直在向前发展。在这个领域真正有用的两个模块是：

Features - 允许您收集内容类型，分类，视图甚至Feed等实体。我们非常成功地使用它，并且可以在开发人员之间共享这些更改。

Strongarm - 允许使用上述模块存储和导出变量。我已经用这个模块做了一些测试，但是我们没有使用它，很简单，因为我们真的不需要这个功能。

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

Answer 4

如果你使用svn:externals属性，你可以省去配置和使用SVN的一些痛苦，如Nick的文章所述。这将使Drupal的本地版本自动与指定的Drupal分支保持同步，并且您可以对模块使用完全相同的机制。另外，因为SVN将从文件中读取外部定义，所以您也可以将它们置于版本控制之下！

我认为CVS不具备同等功能。但是，编写一个简单的脚本非常容易，它会自动安装一个Drupal模块，只需要一个URL（我这样做是为了让我自己的Drupal站点保持最新）。

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

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

Answer 5

某些模块（如CCK和Views）允许以文本形式导出和导入其设置数据。您可以在源代码管理系统下保存这些文本表示。

Answer 6

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

对于配置数据的历史跟踪的版本控制，像backup_migrate这样的模块允许您执行db的自动SQL转储。您可以通过定义备份“配置文件”来选择转储哪些表，并且可以创建一个将大型内容，日志记录和缓存表（例如node，cache_content，watchdog）留出转储的表，以便为版本控制留下更易管理的块。服务器或其他地方的一些简单脚本可以获取最新的转储并将其添加到您的存储库。

Answer 7

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

您还可以通过中央控制器配置文件或模块管理初始，不可导出的配置和配置更改。用它来启用模块，创建用户等。

请参阅The Development -> Staging -> Production Workflow Problem in Drupal和Code driven development: using Features effectively in Drupal 6 and 7演示文稿。

Drupal源控制策略？

7 个答案: