Why don’t you trust your build system?

In this post I’m going to challenge the conventional wisdom that the best place to store configuration information is in XML config files or database entries rather than in code files. A typical comment I see goes something like this “I can’t change routes without recompiling and deploying code. I thought it better to configure routes in a more dynamic environment, specifically the database …”

Some observations:-

​1) Why is ‘recompiling and deploying’ an issue? If you have continuous integration and continuous deployment to a test server it should be a non-issue.

​2) Databases (alone) lack any tracking metadata - who changed what and when? Who do you blame when your site stops working because someone edited the configuration?

​3) Databases and XML files do not provide strong-typing and Intellisense like you can get in the IDE to accesss your configuration settings.

​4) Do you *want* your ops team to be able to edit your configuration settings?

So instead of using XML files that can be changed in production environments by anyone without any tracking, why not build your configuration settings into code files where they can be strongly-typed and are always under version control giving you a full history as to who changed what and when it was changed. If, like me, you deploy several times a day because you trust your build and deployment system this is actually the easiest and safest way to make configuration changes.

Thu Apr 01 2010 01:20:53 GMT-0700 (Pacific Daylight Time)

Next page: Why functional programming and LINQ is often better than procedural code

Previous page: Continuous Integration -> Continuous Deployment

Disqus goes here