在开发、登台和生产之间同步 Drupal 站点
通常在 Drupal (6.x) 站点启动后，我会让人们开始注册并输入他们自己的内容。每当需要升级时，生产中的数据库都会复制到开发版，然后在开发版上完成开发，然后推送到登台以供客户批准。
当网站最终准备上线时，出现了一个问题。生产服务器具有最新的用户输入内容，开发和登台具有最新的功能。简单地覆盖生产数据库是行不通的。我通常做的就是写下开发人员所做的事情，然后按照步骤在生产中再次进行实现。随着系统越来越大，生产上的一个失误就可能导致业务损失。我无法关闭该网站几个小时。我无法知道在给定时间有多少人正在使用该网站，即使如此，也不可能等待网站上没有人的时间来进行升级。
有人有什么好主意吗？
提前致谢。
Often after a Drupal (6.x) site is launched, I have people starting to sign up and enter their own content. Whenever there is need for an upgrade, the database on production is copied to dev and then the development is done on dev, later get pushed to staging for client's approval.
When the site is eventually ready to go live, there is a problem. Production server has the latest user inputted content, dev and staging have the latest functionality. Simply overwriting the database on production won't work. What I usually do is to write down what has been done to dev and than follow the steps to go though the implementations again on production. As the system grows bigger, one single mistake on production may cause lost of business. I can't shutdown the site for several hours. I can't tell how many people are using the site at a given time, even so it's impossible to wait for a time where nobody is on the site to make the upgrade.
Has anyone have any good idea?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您需要研究两个概念：第一个是“Exportables”，这通常是一种导出方式给定模块的所有配置。第二个是“Features”（名字很糟糕，是的），这是一种将一组可导出项分组为的方法用于版本控制、更新、部署、回滚等的给定变更集。
为了澄清，许多模块实现了自己的“可导出”方法，我上面链接的是可导出模块。这是一个更广泛的策略 - http:// www.sthlmconnection.se/tips-and-tweaks/exportable-configuration-your-drupal-module-ctools
There are two concepts you need to look into: The first is "Exportables" which is generally a way of exporting all the configuration of a given module. The second is "Features" (terribly named, yes) which is a way of grouping a set of Exportables into a given changeset for version control, updating, deployment, rollback, etc.
For clarification, many modules implement their own "Exportables" methodology what I linked to above was the Exportables module. Here's a wider strategy for it - http://www.sthlmconnection.se/tips-and-tweaks/exportable-configuration-your-drupal-module-ctools
这是一个价值百万美元的问题：如何在不同的 Drupal 站点之间传输代码、配置和内容？在 Drupal 中，代码存储在文件中（或者至少应该如此），而配置和内容通常存储在数据库中。
将代码从一台服务器转移到另一台服务器并不难，而且代码还有另一个优点：很容易在 SVN 或 GIT 等版本控制系统中存储和管理。这就是为什么大多数解决方案都专注于从数据库中取出内容并将其放入代码中。
CaseySoftware 已经提到过，Features 模块是您在代码中存储配置所需的模块。几周以来，功能已经稳定发布，社区似乎同意功能是前进的方向。
在站点之间移动内容有点困难，因为可以在开发、登台和生产上同时添加或更改内容。 Exportables 是解决这个问题的一种尝试，但它不是唯一的。请确保您还查看了部署和基于功能的UUID 功能集成 模块。这些模块都还不稳定，时间会告诉我们哪一个是最好的解决方案。
It's the million dollar question: How to transfer code, configuration and content between different Drupal sites? In Drupal, code is stored in files (or at least it should be) while configuration and content are usually in the database.
Taking your code from one server to another isn't that hard, and code has another advantage: it's easy to store and manage in a version control system like SVN or GIT. That's why most solutions focus on taking stuff out of the database and putting it into code.
Already mentioned by CaseySoftware, the Features module is what you need to store configuration in code. Features has a stable release since a couple of weeks and the community seems to agree that Features is the way forward.
Moving content between sites is a little harder, because content can be added or changed on dev, staging and production simultaneously. Exportables is an attempt to solve that, but it's not the only one. Make sure you also check out Deploy and the Features-based UUID Features Integration modules. None of those modules is stable yet and time will tell which one is the best solution.