Drupal源代码管理策略？ [英] Drupal Source Control Strategy?

问题描述

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

In standard php or source code based projects we easily keep all of the code in SVN and each developer can checkout their own copy and collaborate on the same code.

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

When developing a Drupal site however, much of the work is in "setup". Besides the theme and modules you don't really have any "source code". How do you run multiple instances of the same site so developers can all work at the same time yet share their work?

示例场景：

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

We launch an initial version of a Drupal site with content type "X" created. We also initially launch a view on the site that lists all the nodes of type "X" in chronological order. The client starts using the site, add content, menu items etc.

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

The next release is planned to add user search ability to that view. The setup for that is contained in the database though. We can copy down the production database to our development version to get the latest data while we work on changing the view. During that time however the client can still be updating the site, making our dev database out of sync. When we are ready to push the new view to production, is there an easier way to do it other than manually repeat the steps to set it up on the production install?

推荐答案

我认为这里的一个很好的策略是使用安装配置文件API。使用安装配置文件API，您可以使用Drupal管理工具做的大部分事情。大多数核心表单只是在变量表中设置变量。为了能够明智地版本您的非内容数据库内容，即配置，使用更新功能是明智的。

I think a good strategy here is to use the install profile API. With install profile API you can do most things that using the Drupal admin tools do. Most core forms simply set variables in the variables table. To be able to sensibly version your non content database contents i.e. configuration it is wise to use update functions.

在我的网站上，我们有一个模块ec除了它的ec.install文件包含更新功能，例如ec_update_6001（）

On my site we have on module "ec" that does very little apart from have it's ec.install file contain update functions e.g. ec_update_6001()

您的主要安装功能可以在您进行任何新安装时实际运行更新，使您的模块更新。

Your main install function can take care of actually running the updates on any new installs you make to bring your modules up to date.

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

Effectively this mostly solves the versioning problem with databases and Drupal code. We use it extensively. It allows us to promote new code which changes database configuration without having to reimport the database or make live changes. This also means we can properly test releases without fear of hidden database changes.

最后cck和视图支持这种方法。查看此代码片段

Finally cck and views support this approach. See this code snippet

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

这篇关于Drupal源代码管理策略？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！