Common Development Patterns: Settings per Environment

I am thinking of doing a range of blog posts related to common development patterns that I have seen implemented. These are not exactly Design Patterns, but practices that I see and have implemented myself.

To kick of this series, I thought I would talk about your application's settings depending on environment. As a background I was working on a Galleon application that in development runs on Apache with MySQL and in Staging/Live it runs on IIS and MS SQL. Generally you want to keep your environments the same of course, but the main changes were simply table names, emails and URLs so all the code was fine.

One of the things that annoyed me was that before I could check in my code to SVN, I would have to change the settings.ini.cfm file, putting all the live settings in there.

Since Galleon is not built on any framework, I decided to just easily plug in a config detector, so I could use a different settings file, settings.local.ini.cfm and not have to to change the main config.

I did this simply where the settings file is included so for Galleon I put this in the code:

(I have removed a lot of other code round it to make it simple)

This is a simple replacement, that is based on the CGI_SERVER_NAME

You could of course get a bit fancier, depending on the name of the physical machine, but you have to drop into Java and get the actual machine's host (rather than what I have placed in the URL, since you might be replicating the live site with an entry in your hosts file):

If you are using ColdBox, you can just add the EnvironmentControl interceptor in your config/coldbox.xml.cfm:

config/environments.xml.cfm false

And in your config/environments.xml.cfm you can override any settings just by adding them to the correct section:

If you are using ColdSpring for your configuration, you might want to do a couple of things, first thing you can do is simply call in a different coldspring.xml.cfm file when you create your bean factory, but to do this you would have to copy all your beans. The easiest way is to have the root coldspring.xml.cfm file have any settings that you want in a (configBean for example) and then include your main coldspring file.

So, wherever we are loading Coldspring up we can put an environment logic:

In the coldspring.xml.cfm file we would have:

Project projectDatabase [email protected] production

This would setup the Config bean that is passed to other objects and fill it with values that are required and then include the SharedColdSpring.xml that doesn't really need any changing per environment

In my coldspring.markdrew.xml.cfm I would have the same but with my settings:

Project devDB mark@localhost development

I hope this gives you some ideas on how to remove some effort from your work day!