Use source control, NOT FTP/etc., for the files. It doesn't matter what you use; we tend to spin up an Unfuddle.com subversion account for each client so they have a place to log bugs as well, but the critical first step is getting the full source tree of your site into version control. When changes are made on the testing server or staging server, you see if they work, you commit, then you update on the live server. Rollbacks and deployment gets a lot, lot simpler. For clusters of multiple webheads you can repeat the process, or rsync from a single 'canonical' server.
If you use SVN, though, you can also use CVS checkouts of Drupal and other modules/themes and the SVN/CVS metadata will be able to live beside each other happily.
For bulky folders like the files directory, use a symlink in the 'proper' location to point to a server-side directory outside of the webroot. That lets your source control repo include all the code and a symlink, instead of all the code and all the files users have uploaded.
Databases are trickier; cleaning up the dev/staging DB and pushing it to live is easiest for the initial rollout but there are a few wrinkles when doing incremental DB updates if users on the live site are also generating content.
Features.module is an extremely powerful tool for managing Drupal configuration changes.
Content Types, CCK settings, Views, Drupal Variables, Contexts, Imagecache presets, Menus, Taxonomies, and Permissions can all be rolled into a feature, which can be checked into version control. From there, deploying a new site, or pushing changes to an existing one, is easily managed with the Features UI or Drush.
Make sure you install Strongarm.module for exporting drupal config that gets stored in your Variables table. You can also static content/nodes (ie: about us, faqs, etc) into Features by installing uuid_features.module.
Hands down, this is the best way to work with other developers on the same site, and to move your site from Development to Testing to Staging and Production.
We've had an extensive discussion on this at my workplace, and the way we finally settled on was pushing code updates (including modules and themes) from development to staging to production. We're using Subversion for this, and it's working well so far.
What's particularly important is that you automate a process for pushing the database back from production, so that your developers can keep their copies of the database as close to production as possible. In a mission-critical environment, you want to be absolutely certain a module update isn't going to hose your database. The process we use is as follows:
Install a module on the development server.
Take note of whatever changes and updates were necessary. If there are any hitches, revert and do again until you have a solid, error-free process.
Test your changes! Repeat your testing process as a normal, logged-in user, and again as an anonymous user.
If the update process involved anything other than running update.php, then write a script to do it.
Copy the production database to your staging server, and perform the same steps immediately. If it fails, diagnose the failure and return to step 1. Otherwise, continue.
Test your changes!
BACK UP YOUR PRODUCTION DATABASE and TAKE NOTE OF THE REVISION YOU HAVE CHECKED OUT FROM SVN.
Put your production Drupal in maintenance mode, run "svn update" on your production tree, and go through your update process.
Take Drupal out of maintenance mode and test everything (as admin, regular user, and anonymous)
And that's it. One thing you can never really expect for a community framework such as Drupal is to be able to move your database from testing to production after you go live. From then on, all database moves are from production to testing, which complicates the deployment process somewhat. Be careful! :)
I'm surprised that no one mentioned the Deployment module. Here is an excerpt from its project page:
... designed to allow users to easily stage content from one Drupal site to another. Deploy automatically manages dependencies between entities (like node references). It is designed to have a rich API which can be easily extended to be used in a variety of content staging situations.
I don't work with Drupal, but I do work with Joomla a lot. I deploy by archiving all the files in the web root (tar and gzip in my case, but you could use zip) and then uploading and expanding that archive on the production server. I then take a SQL dump (mysqldump -u user -h host -p databasename > dump.sql), upload that, and use the reverse command to insert the data (mysql -u produser -h prodDBserver -p prodDatabase < dump.sql). If you don't have shell access you can upload the files one at a time and write a PHP script to import dump.sql.
Any version control system (GIT, SVN) + Features module to deploy Drupal code + custom settings (content types, custom fields, module dependencies, views etc.).
As Deploy module is still in development mode, so you may like to use Node export module in Drupal 7 to deploy your content / nodes.
If you're new to deployment (and or Drupal) then be sure to do everything in one lump. You have to be quite careful once there are users effecting content while you are working on another copy.
It is possible to leave the tables that relate to actual content, taxonomy, users, etc. rather than their structure. Then push the ones relating to configuration. However, this add an order of magnitude of complexity.
Apologies if deployment is something old hat to you, thus this is vaguely insulting.
A good strategy that I have found and am currently implementing is to use a combination of the deploy module to migrate my content, and then drush along with dbscripts to merge and update the core and modules. It takes care of database merging even if you have live content, security and module updates, and I currently have mine set up to work with svn.
发布评论
评论（9）
一些提示：
对文件使用源代码管理，而不是 FTP/等。 你用什么并不重要； 我们倾向于为每个客户建立一个 Unfuddle.com 颠覆帐户，以便他们也有一个记录错误的地方，但关键的第一步是将站点的完整源代码树纳入版本控制。 当在测试服务器或登台服务器上进行更改时，您会看到它们是否有效，然后提交，然后在实时服务器上进行更新。 回滚和部署变得非常非常简单。 对于多个网络头的集群，您可以重复该过程，或从单个“规范”服务器进行 rsync。
如果您使用 SVN，那么您还可以使用 Drupal 和其他模块/主题的 CVS 签出，并且 SVN/CVS 元数据将能够愉快地共存。
但是，
对于像文件目录这样的大文件夹，请在“正确”位置使用符号链接指向 Webroot 之外的服务器端目录。 这可以让您的源代码控制存储库包含所有代码和符号链接，而不是所有代码和用户上传的所有文件。
数据库比较棘手； 对于初始部署来说，清理开发/登台数据库并将其推送到上线是最简单的，但是如果实时站点上的用户也在生成内容，那么在进行增量数据库更新时就会出现一些问题。
去年，我做了一个关于 Drupal 部署最佳实践的演示。 请随意查看幻灯片。
A couple of tips:
Use source control, NOT FTP/etc., for the files. It doesn't matter what you use; we tend to spin up an Unfuddle.com subversion account for each client so they have a place to log bugs as well, but the critical first step is getting the full source tree of your site into version control. When changes are made on the testing server or staging server, you see if they work, you commit, then you update on the live server. Rollbacks and deployment gets a lot, lot simpler. For clusters of multiple webheads you can repeat the process, or rsync from a single 'canonical' server.
If you use SVN, though, you can also use CVS checkouts of Drupal and other modules/themes and the SVN/CVS metadata will be able to live beside each other happily.
For bulky folders like the files directory, use a symlink in the 'proper' location to point to a server-side directory outside of the webroot. That lets your source control repo include all the code and a symlink, instead of all the code and all the files users have uploaded.
Databases are trickier; cleaning up the dev/staging DB and pushing it to live is easiest for the initial rollout but there are a few wrinkles when doing incremental DB updates if users on the live site are also generating content.
I did a presentation on Drupal deployment best practices last year. Feel free to check the slides out.
功能.module 是一个用于管理 Drupal 配置更改的极其强大的工具。
内容类型、CCK 设置、视图、Drupal 变量、上下文、图像缓存预设、菜单、分类法和权限都可以整合到一个功能中，并可以签入版本控制。 从那里，可以使用功能 UI 或 Drush 轻松管理部署新站点或将更改推送到现有站点。
确保安装 Strongarm.module 以导出存储在变量表中的 drupal 配置。 您还可以通过安装 uuid_features.module 将静态内容/节点（即：关于我们、常见问题解答等）添加到功能中。
毫无疑问，这是与同一站点上的其他开发人员合作以及将站点从开发转移到测试再到登台和生产的最佳方式。
Features.module is an extremely powerful tool for managing Drupal configuration changes.
Content Types, CCK settings, Views, Drupal Variables, Contexts, Imagecache presets, Menus, Taxonomies, and Permissions can all be rolled into a feature, which can be checked into version control. From there, deploying a new site, or pushing changes to an existing one, is easily managed with the Features UI or Drush.
Make sure you install Strongarm.module for exporting drupal config that gets stored in your Variables table. You can also static content/nodes (ie: about us, faqs, etc) into Features by installing uuid_features.module.
Hands down, this is the best way to work with other developers on the same site, and to move your site from Development to Testing to Staging and Production.
我们在我的工作场所对此进行了广泛的讨论，我们最终确定的方式是将代码更新（包括模块和主题）从开发到暂存再到生产。 我们正在使用 Subversion 来完成此任务，到目前为止它运行良好。
特别重要的是，您可以自动化将数据库从生产中推回的过程，以便您的开发人员可以使他们的数据库副本尽可能接近生产。 在关键任务环境中，您希望绝对确定模块更新不会损坏您的数据库。 我们使用的过程如下：
就是这样。 对于像 Drupal 这样的社区框架，您永远无法真正期望的一件事是能够在上线后将数据库从测试转移到生产。 从那时起，所有数据库移动都是从生产到测试，这使部署过程有些复杂。 当心！ :)
We've had an extensive discussion on this at my workplace, and the way we finally settled on was pushing code updates (including modules and themes) from development to staging to production. We're using Subversion for this, and it's working well so far.
What's particularly important is that you automate a process for pushing the database back from production, so that your developers can keep their copies of the database as close to production as possible. In a mission-critical environment, you want to be absolutely certain a module update isn't going to hose your database. The process we use is as follows:
And that's it. One thing you can never really expect for a community framework such as Drupal is to be able to move your database from testing to production after you go live. From then on, all database moves are from production to testing, which complicates the deployment process somewhat. Be careful! :)
我们广泛使用功能模块来捕获功能，然后在生产站点轻松安装它们。
We use the Features module extensively to capture features and then install them easily at the production site.
我很惊讶没有人提到 Deployment 模块。 以下是其项目页面的摘录：
I'm surprised that no one mentioned the Deployment module. Here is an excerpt from its project page:
我不使用 Drupal，但我经常使用 Joomla。 我通过归档 Web 根目录中的所有文件（在本例中为 tar 和 gzip，但您可以使用 zip）进行部署，然后在生产服务器上上传并扩展该归档文件。 然后，我进行 SQL 转储（mysqldump -u user -h host -p databasename > dump.sql），上传该数据，并使用反向命令插入数据（mysql -u produser -h prodDBserver -p prodDatabase < dump） .sql）。 如果您没有 shell 访问权限，您可以一次上传一个文件并编写一个 PHP 脚本来导入 dump.sql。
I don't work with Drupal, but I do work with Joomla a lot. I deploy by archiving all the files in the web root (tar and gzip in my case, but you could use zip) and then uploading and expanding that archive on the production server. I then take a SQL dump (mysqldump -u user -h host -p databasename > dump.sql), upload that, and use the reverse command to insert the data (mysql -u produser -h prodDBserver -p prodDatabase < dump.sql). If you don't have shell access you can upload the files one at a time and write a PHP script to import dump.sql.
任何版本控制系统（GIT、SVN）+用于部署 Drupal 代码的功能模块+自定义设置（内容类型、自定义字段、模块依赖项、视图等）。
由于 Deploy 模块仍处于开发模式，因此您可能喜欢使用 节点导出 模块用于部署您的内容/节点。
Any version control system (GIT, SVN) + Features module to deploy Drupal code + custom settings (content types, custom fields, module dependencies, views etc.).
As Deploy module is still in development mode, so you may like to use Node export module in Drupal 7 to deploy your content / nodes.
如果您是部署（和/或 Drupal）的新手，请务必一次性完成所有操作。
一旦有用户在您处理另一个副本时影响内容，您就必须非常小心。
可以保留与实际内容、分类、用户等相关的表格，而不是其结构。 然后推送与配置相关的内容。 然而，这增加了一个数量级的复杂性。
抱歉，如果部署对您来说是老生常谈，因此这有点侮辱性。
If you're new to deployment (and or Drupal) then be sure to do everything in one lump.
You have to be quite careful once there are users effecting content while you are working on another copy.
It is possible to leave the tables that relate to actual content, taxonomy, users, etc. rather than their structure. Then push the ones relating to configuration. However, this add an order of magnitude of complexity.
Apologies if deployment is something old hat to you, thus this is vaguely insulting.
我发现并正在实施的一个好策略是使用部署模块的组合来迁移我的内容，然后与 dbscripts 一起合并和更新核心和模块。 即使您有实时内容、安全性和模块更新，它也会负责数据库合并，并且我目前已将我的设置为与 svn 一起使用。
A good strategy that I have found and am currently implementing is to use a combination of the deploy module to migrate my content, and then drush along with dbscripts to merge and update the core and modules. It takes care of database merging even if you have live content, security and module updates, and I currently have mine set up to work with svn.