When working with web applications we often, very often, face the problem that the configurations in the various environments where the application will be deployed differ from one another. This could be anything from different datasource names, security credentials, email server address and most important it could be an application setting to set your application mode (dev mode, live mode). I say “most important” because if you have an e-commerce this flag could be the difference between charging customers or letting every transaction go through (Free goodies!).
A way to deal with this problem (I believe the most commonly adopted) is to use a config file to set all this properties. That’s where the famous “.ini” comes in (or XML), which is that text file with the variables for an environment. It does the job but now you have a config file per environment and this could be a local, a dev, a staging and a production file. So, now you have another problem, which is you have to make sure not to replace any of these files every time you do an update to your app (been there, done that). You can use Ant to avoid making this mistake but you still have multiple copies of the config file lying around. So, what if you can have a single file that “knows” what properties and values to use depending on the environment that is at?
Rob Gonda and I, created a very simple environment configurator that works of a single XML file and sets the needed properties based on the server is at. We did this over a year ago but neither of us took the time to blog about it. Now that I still see developers using multiple config files, I’ve decided post this as a small project on RIAForge.org. I’ve called it Environment Config for lack of creativeness, I guess.
The basics:
It consists of 2 files, one XML file and one CFC. In the XML file you define all your environments and properties and pass the location of the file to the CFC which will parse your XML file and return a structure with the properties. Is that simple!
The Anatomy of the Environment XML:
The XML structure has two main elements, “default” and “environment”.
Default - Under default you add those properties that are common to all your environments
Environment – Define one per server environment.
Pattern – Inside Environment you’ll find the Patterns element which contains the Pattern. This is a Regex string that holds the server’s name or a Regex pattern. So you can enter something like: “^myapp.local” or “^.*.local” to match anything that ends in “.local”. You can define as many Pattern elements as needed per environment.
Property – Also located inside the Environment is the config element which contains the Property. You can define as many Property elements as needed per environment. If you define a property that was defined in the Default element, it will be overwritten by the one in the Environment.
If you look at the sample environment.xml, you’ll notice that in the production environment, the pattern is defined as ‘.*’ which is pretty much a “catch all” pattern. I recommend using this for production environments so that later on you don’t get a call from your client asking you why his site is broken since he acquired a new domain.
Thanks for your feedback and suggestions!
[hide extended entry]
