How do the different frameworks and cmses handle the dev > staging > production deployment problem?

Question

It's a familiar problem: I've got some changes to push up the dev > staging > production chain, but in the mean time, content and users have been added to the database on the production server.

I work with drupal a lot, and it's lousy at this because so much of the configuration winds up in the db. (There are some solutions that try to address it, but nothing fully solves the problem, or makes it as easy as it would be if all the configuration could be published via the VCS.)

This has made me curious about how the other guys handle it? I imagine WordPress has the same sorts of issues since AFAIK, it's configuration lives largely in the db. What about Django? Rails? .NetMVC? CodeIgnighter? Kohana? Etc.?

(I'm aware that there's a bit of an apples-to-oranges comparison here since I've got both frameworks and CMSes mixed together, and the frameworks probably have a huge advantage, but maybe they run into the same sorts of issues, and maybe they have some nice solutions. Hence the question...)

Answer 1

Hey Sprugman,

I've been doing a lot of research in this area. We use Joomla for most of our projects, but we have very experienced Drupal people on the team as well.

I started a Google Wave that summarized the research that we've been doing on this subject, if you'd like me to add you to it, please email me at [email protected]

Taras

Answer 2

Morning,

ZendFramework has the application.ini file seperated into different sections:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0

doctrine.dsn                = "mysql://root:[email protected]/dbname"

log.file = APPLICATION_PATH "/../logs/importer.log"
log.level = 6

[staging : production]
log.file = APPLICATION_PATH "/../logs/importer_staging.log"

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1

doctrine.dsn                = "mysql://root:[email protected]/dbname_testing"

resources.frontController.throwExceptions = 1

log.file = APPLICATION_PATH "/../logs/importer_testing.log"
log.level = 7

[development : testing]
doctrine.dsn                = "mysql://root:[email protected]/dbname_development"
log.file = APPLICATION_PATH "/../logs/importer_development.log"

And then based on the define('APPLICATION_ENV', 'development') this will use that specific section. Using [enviroment : inherit] means you don't need to redeclare all of the settings just those that change with the different enviroment

I know this doesn't help from the setting stored in a database point of view, but I just use an ini file (old skool but it works)

HTH

Answer 3

I ran into the same issues when I was running Drupal sites. Drupal is particularly tricky in this department.

These modules look quite interesting in addressing this issue: http://developmentseed.org/blog/2009/jul/09/development-staging-production-workflow-problem-drupal

Answer 4

In Java world it is often done next way:

Have two different configuration files:

1. /src/main/resources/foo.properties for staging
2. /src/test/resources/foo.properties for test

Build engine is usually Maven, so it uses one of them depending on how it was called:

• ">mvn compile" uses properties from main directory
• ">mvn test" uses properties from test directory

When project is released on production, developers instruct administrators what to change in .properties files (usually URLs and passwords).