DevOps Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 544 posts at DZone. You can read more from them at their website. View Full User Profile

Database configuration: Just like any other change

08.18.2010
| 3935 views |
  • submit to reddit

I've been flicking through Continuous Deployment and one section early on about changing configuration information in our applications particularly caught my eye:

In our experience, it is an enduring myth that configuration information is somehow less risky to change than source code. Our bet is that, given access to both, we can stop your system at least as easily by changing the configuration as by changing the source code.

In many organisations where I've worked this is generally adhered to except when it comes to configuration which is controlled from the database!

If there was a change to be made to source code or configuration on the file system then the application would go through a series of regression tests (often manual) to ensure that the application would still work after the change.

If it was a database change then that just be made and there would be no such process.

Making a change to database configuration is pretty much the same as making any other change and if we don't treat it the same way then we can run into all kinds of trouble as the authors point out:

If we change the source code, there are a variety of ways in which we are protected from ourselves; the compiler will rule out nonsense, and automated tests should catch most other errors. On the other hand, most configuration information is free-form and untested.

Alex recently wrote about his use of deployment smoke tests – another suggestion of the authors – to ensure that we don't break our application by making configuration changes.

Organisations often have painful processes for releasing software but I think it makes more sense to try and fix those rather than circumnavigating them and potentially making our application behave unexpectedly in production.

References
Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)