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.

Comstock

+1 to compensate for shortened lifespan. That also shocked me. – Feisty

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.

Mignon

+1 for the links. I like the use of modules for update. Is there anything about the process you would improve? – Comstock

Your development and deployment setup is really cool.. Do you have a link or an article on how you got all this working together? Capistrano, simpletest, etc? Have you used Cruise Control? Pointers to interesting articles will be nice. – Bicarb

@Bicarb I think you can get an overview here archive.org/details/TransformingTheEconomistOnlineusingDrupal – Mignon

@Ryan The biggest issue we have is that we run updates incrementally on our integration server but as a batch on live. This can behave slightly differently, so we are building an instance where we will import the live data daily and test the update works as a batch. – Mignon

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.

Franchot

great answer, developmentseed is one of those lovely companies ;) – Callicrates

+1 flamingLogos for the signpost to development seed and Sepehr Lajevardi for the positive feedback on them. – Deus

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.

Heedless

Do you know of a better CMS? Or am I back to "roll your own". – Comstock

I'd rather not move into that territory. In my experience this is a weakness with most open source cms'es. Personally, I'm very much a roll-your-own guy, but there are plenty of reasons for this not being the best solution. If you look outside cms'es, Rails have a very nice deployment pipeline. It's not php, but you can perhaps transfer the concepts. – Heedless

@Heedless thanks, i'll check rails out. As i mentioned in my post this is all about farting around anyway :) – Comstock