views:

56

answers:

2

Hi all,

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.

A: 

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

CaseySoftware
A: 

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.

marcvangend
Thx. That's exactly what I am trying to solve but just not sure if there is any done done solution out there. Interesting enough, I think I just took Drupal from granted as anything i have thought of doing with Drupal, there is a module for it. I read and article a while ago using Feature and Context to manage this problem. After trying for a while I find that the Context module isn't very stable. Exporting is the way to go but the problem is each module has it's own export tools. Over time I still have to keep track of what chance has been made for each update.
Desmond Liang
Article that i mention highlights the fundamental point of achieving this goal is by separating configuration and content, in other wolds let SVN manages configuration and latest data should always come form the database on production. In my opinion, it's actually okay if the configs are in the database as long as Drupal can come up a naming convention that clearly separates tables that contain only configs and table that contains user data only.
Desmond Liang