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?
These records need to be updated whenever a release is deployed.
So, how are these records kept?
If you choose to perform incremental releases, it seems easy to "just keep the releases". So if you want to know what is in live "right now", then you:
- get the list of the initial release
- overlay with the list from release #1
- overlay with the list from release #2
- overlay with the list from release #3
- etc etc ad nauseum
| Next > |
|---|
