Syncing Drupal site between dev, staging and produ

问题:

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.

回答1:

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

回答2:

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.