I generally end up working in large organisations where the software you deal with is an accretion of good and bad ideas implemented in a haphazard fashion and held together with spit and string.  Much of the complexity within these environments comes down to configuring all these disparate pieces of technology to communicate with each other correctly, and there seems to be a standard set of approaches you find people using to manage the complexity of this configuration.

Of these, there seems to be about seven common ways of applying configuration change to an application (give or take absurdity).  There are also a bunch of ways to model and store the interactions between configuration, but that is another post.

  1. Level 1 – Compiled
    You need a new configuration for a test environment?  Sure.  Let me compile that in statically for you.  Seriously.  I know of at least one major bank who think this is the way to manage software deployment!
  2. Level 2 – Notepad
    If you need to change a configuration file, you go onto the server and change it.  No fuss, no muss.  Also, no record, no control and not a good idea.
  3. Level 3 – Duplicative
    Files that are required to be different per environment are copied and modified per environment, stored somewhere, and copied into place as required.  Results in a single change being made in multiple copies of the same file, one change per environment.  This approach requires:
    1. A copy of each file that needs custom settings, stored in some central location.
    2. A lot of patience.  Making the same change to a bunch of files gets boring real fast.
  4. Level 4 – Tokenized
    Settings that are required to be different per environment or instance are replaced with tokens in a set of configuration files that are then stored as templates.  These tokens are then replaced with a generated value at deployment or installation time to provide the correct value.  Generally the first of the more structured approaches you find in larger environments.  Also one of my absolute pet hates.  This approach requires:
    1. The target configuration file to be stored and treated as a *template, *as it must contain the tokens in the correct locations.
    2. A transform file that lists the replacement values per environment or instance.
    3. A tool to do the replacement.
  5. Level 5 – Declarative
    Changes are listed as a set of declarative modifications to configuration files, these changes are then grouped by environment.  This is different to a tokenized approach as you do not need to use templates per se, as you declare the config change you required to a file regardless of the existing contents of the target file.  An example of this is http://code.google.com/p/renderconfig. For this approach, you need:
    1. A file detailing a set of declarative changes, usually the data required can be paired down to “Environment, FilePath, XPath, Value” or something similar.
    2. A set of target files that exist somewhere.  They are typically stored with the software build output, or on a server, or in source control (or anywhere else really).
    3. A tool to do the transform.
  6. Level 6 - Subscriptive
    Changes are subscribed to or requested from a central service, and are not held locally (unless cached).  In its pure form, this approach requires code changes to allow a piece of software to subscribe to published configuration changes, or request updates.  Generally the only locally held configuration required is a pointer to the configuration service at an application level, and an identifier for the configuration set required by a particular software module.  This is probably one of the most advanced configuration setups, and it is rare to see (particularly in banks!).  This requires:
    1. A centralised configuration service.
    2. A set of client tools to request and provide configuration.
    3. A set of tools to set and manage the configuration to be published.
  7. Level 7 - Autonomic
    You don’t tell the software, it already knows.  I think this is how Skynet was configured.

Getting to Level 4 or above should generally be the aim, although having dealt with the pain of large organisations running tokenised systems before I will spend some time trying to convince you of the folly at a later date.  If you had a look around, where do you think your organisation is at?