How are people handling content management system production staging?

Question

I've been dipping my toe into web development technologies for fun (ya, i should get out more), and am a little shocked at the lack of clear support for production staging (i.e. development, testing, performance, and production environments). Actually support isn't the word; Content Management Systems seem to actively work against efforts to allow for clean staging.

Currently I am using Drupal. I have had a very hard time finding how the community solves this problem. Most of the posts I've seen recommend reproducing the steps done in development on the production system (reading this actually shortened my life a small bit). I also hear of pushing production data back to the developers so they can add incremental features. This can't be the way to go, what if the client doesn't want you pulling their data back to your development environment?

So finally my question:

How are you managing real world production staging issues for a CMS?

I come from a background where pushing to production feels like sending people to the moon, so I may need to relax a little bit. However I am still interested answers that involve source control, allow for production rollback, and testing.

Answer 1

I have answered a question on DB deployment strategies.

There is also a question on code deployment.

Where I work we are working on a fairly large Drupal deployment. We have roughly the following setup.

All developers have a local sandbox (Drupal + DB). The commit code to a branch that is shared among all of the other developers (there are around 15 of us). This includes configuration changes which are performed by update functions.

When developers do a svn up, they also run update.php to perform any configuration changes locally.

We have a sprint testing system which runs simpletest and can be used for user testing.

At the end of a sprint (we use scrum), we merge the branch into trunk, and run tests on this.

We then tag this as a release and deploy it to live (using Capistrano), finally run update.php on live to apply configuration changes to live.

Any emergency fixes get deployed from trunk to live as a dot release 7.1 etc.

If you want any more detail then please leave a comment.

Answer 2

After investing a few weeks getting over the Drupal learning curve, the "too much configuration is stored in the DB" issue is very disconcerting if you're building a site of any complexity.

Take a look at the work that Development Seed is doing to work around this problem. They are leading the development of the Context, Features, and Spaces modules that work together to store configuration data in modules (outside of the DB) so that it can be versioned with the code.

Answer 3

Currently I am using Drupal. I have had a very hard time finding how the community solves this problem.

It's one of the weaknesses of Drupal; It really doesn't deal properly with this matter. It's particularly hard to sort out because a large part of the configuration of Drupal resides in the database.