How to plan IT system upgrades and releases
Whenever I start talking to people about release management, I always feel like I am making excuses because it is such a dry topic. Once again, it plays (unfortunately) into the sexist male view that:
a) we don’t like to plan
b) we don’t read the instructions
Give any bloke a new DVD recorder and I am sure he will plug it all in and go for the remote before he even picks up the instruction book! But the first aspect of release management is all about planning and it is all about picking up the instruction book (so if any companies out there are thinking about introducing release management, consider a lady for the job before a man).
Now as I have probably broke every HR rule I had better explain myself. Release management is about getting from A to B in a controlled and planned way.
Take a common situation:
Company A runs an office with 5 PC’s (3 on Windows Vista and 2 on Win 7). They would like to introduce and new accounting package which will supposedly run on both machines. At the same time they would like to install an upgrade version of Adobe Writer on all of the machines. ITIL recommends 3 ways that this can be approached and gives each method a name:
Full Release: This is where the full end to end release is testing in an isolated environment with every component that could be used is bought into the testing program. In our example, the company would ring-fence one of the Vista or one of the Win 7 machines then load the accounting package and Adobe on them, check they work OK and check the file sharing capabilities and compatibility of the other programs before rolling out the changes to the rest of the PC’s of the same operating system.
Delta Release: This is where the only thing that is tested is the actual item being changed. In our instance we could look at each of the new applications as individual items but ignore the fact that they are on different operating systems or the fact that we want to check the compatibility of other application functionality or file sharing. Each of the upgrades (Accounting package and Adobe) would be treated as two different releases and would be done independent of each other.
Package Release: This approach takes concept of the Full and Delta release and rolls them in together to ensure that as many changes are done at the same time (therefore reducing the number of times major upgrades are done). In the example of our Vista and Win 7 estate, a package release would try to co-ordinate the upgrade of both the operating systems at the same time (and it could include other changes such as the introduction of a service pack or some new printer drivers).
So which is the best approach? Well unfortunately there is not an easy correct answer; all three have their own risks and merits.
For example, the Package release reduces the frequency of your changes (therefore reducing the disruption to your service) but if you plan too many releases in the same package and something goes wrong, you don’t know which one caused the problem and therefore which one to back out. The Full release sounds like the safest way to go, but how many companies have a spare end to end environment or can afford to take some machines out of use for a while. Which leaves the Delta release – quick, minimal disruption, only test what we need to BUT the risk lies around the fact that you might have an old application or spreadsheet that uses the data from your new upgraded system and when you do upgrade you find it does not work.
So I have probably not answered many questions on this one, but hopefully I have introduced the concept of how releases can be planned and why you can not just plug it in and grab the remote – sometimes you must read the manual!
