Jorgensen.org.uk

There are two basic approaches to deploying application releases:

• Full Releases: A release contains the whole application
• Incremental Release : The release contains only changes since the previous release.

If implemented correctly, both can work in any organisation. And since very few organisations actually bother tracking releases, most choose incremental releases, because they are easier to implement. And this is where things start going wrong.

The most basic ethos in configuration management is to keep track what is installed.This is extremely important for several reasons. Basically, if you do not know what is installed, then:

• how can the test environment be relied upon? This needs to be as close as technically possible to the live environment to have the same bugs/features as the live environment.
• how can you predict how the application will behave? You need to. If not, then your documentation is unlikely match the application...
• how do you know what has changed in a release?

Many IT departments are sensible enough to use Version Control tools (e.g. CVS or Subversion) to manage their software. For example each application is declared to be its own "project", and releases are done from there.

This tends to work well. At least for organisations where:

• there is no separate testing environment
• and each project has a small number (e.g. 3) of developers

Once the number of developers increase, or the demand for a separate testing environment raises its head, releases tend to go wrong.