首页 文章

Drupal源控制策略?

提问于
浏览
33

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

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

示例场景:

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

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

7 回答

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

    我刚才写了一篇关于painless Drupal revision control with CVS and Subversion最佳实践的文章 .

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

  • 1

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

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

    Strongarm - 允许使用上述模块存储和导出变量 . 我需要这个功能 .

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

  • 12

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

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

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

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

  • 0

    某些模块(如CCK和Views)允许将其设置数据导出和导入为文本 . 您可以在源代码管理系统下保存这些文本表示 .

  • 1

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

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

  • 11

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

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

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

相关问题