Slashdot Mirror
Managing Environment Specific Config Files?
byrnereese asks: "It seems that every organization I have worked for has been plagued with the same problem: 'how do you effectively manage multiple environment configurations for the various development, staging and production environments that exist.' For example, each application at our company requires a different set of database credentials for each environment we deploy it to. For a long time we have maintained different config files for each environment and checked them into our SCCS; but that has proved incredibly error prone because a different build is required for each environment. Each company I have worked for utilizes a different systemology to make config file management a little easier, but none of them have stumbled upon anything that is any less error prone, or any easier to manage than any other solution to choose from. So I am curious, how does your company manage environment specific application configuration? And what does your change management process for these configurations look like?"
At one company I worked for, someone had built a very small application which handled switching environments and all the associated settings. While the implementation was very crude, it was also quite effective. The applications we were developing were Windows-based and written in Visual Basic. The environment manager was customisable (to an extent) and used an INI file to describe each of the possible environments (dev, system test, UAT, production, training, demo), where to find the relevant versions of the files that were required and any relevant registry entries. User's were able to switch between different environments relatively easily and it worked quite well. We had a seperate directory set up for each environment which contained a complete set of files for that environment. Each time a new build was done, the environment's directory was updated, and when the users ran the environment manager only the changed files were copied to their machine. This tool was also used to roll out new versions of the applications, effectively replacing bulky windows installers. (Okay, there was still one initial setup program that needed to be run to initially install the software, but after that the environment manager did the rest.)
All the meta-data for the environment manager was kept under source-control, and the users executed the environment manager from the network. (They could optionally run it locally, but it was then pointed to the network to make sure it was getting the correct INI file.) The only minor complication was that after a build, the environment directory needed to be updated on the network with the latest executables, however this was easily integrated into our build/roll-out procedures. We tagged each release in our source-control system, and were able to easily roll-back any environment if needed.
each environment was based on a user-name. All environemnts with a particular username were assumed the same. For example, we had 3 live servers, 1 dev and 1 stage (total of 5 boxes). On the 3 live servers, the UNIX user was named 'live'. 'stage' and 'dev' on the stage an dev boxes.
Then, each config file in the SCCS was named configfile.logname, so you end up with: somefile.conf.live
somefile.conf.stage
somefile.conf.dev
somefile.conf.joeprogrammer
somefile.conf.bobarchitect
and so forth.
The build script would then either symlink or copy the file for the user running it to the right place:
cd /etc/conf/myapp ; ln -s /build/conf/somefile.conf.$LOGNAME somefile.conf
When symlinking and using CVS, updates to /build/conf get reflected in /etc/conf/myapp
Occasionally, we would need something more complicated than just config files, and so there were scripts that could abstract out the global configuration parameters from the environment specific ones and then glue them together:
In the simplest case the script does:
cat /build/conf/global_opts.conf /build/conf/environment_opts.conf.$LOGNAME > /etc/conf/myapp/config.conf
That said, on any project you must have a release engineer, even if not full time, one person on the project should be assigned the duty of handling the build and release procedures. This includes updating all conf files, and disemenating changes to the group. No tool can replace good team communication. I view systems like what I described as something the release engineer deals with and as a tool for him/her to increase efficiency. The developers should just be able to type 'make' (or equiv) and have it all work out.
Pros: Simple, based on standard UNIX stuff, little or no secret sauce.
Cons: Tougher to get it to work in cross-platform environment, doesn't handle potentially complicated configuration files, requires a person full or part time to administer and maintain.
http://www.naildrivin5.com/davec
See environ for a nice package that does this sort of thing and uses Perl code to manipulate your environment.
As far as books go, you can check out A Guide to Software Configuration Management (Artech House Computer Library) as a reasonable book on the concepts and issues around CM.
There are at least two lists on Amazon of books on this issue: here's one
And of course, Google has a whole directory on configuration management.
HTH -Peter