Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Mon Feb 26, 2007 2:42 am Post subject:
You're going to have a problem with this one, as ITIL's definition and descriptions of a Release are not wholly accurate, when compared to how Product Management teams (Software development, Engineering, etc.) treat and manage Releases.
NOTE: Product Management is not handled by ITIL and is, in my experience, the most critical discipline of all.
To Product Management teams, a Release is nothing more than a "version" of the Product. Each Product Version (a.k.a. a Release) encompasses three types of work:
- Implementation of new features, frameworks, etc.
- Enhancement of existing features, frameworks, etc.
- Correction of defects/problems
The drivers for any and/or all of these types of work are typically Requirements, Risks, and Problems (a.k.a. Defects). As Product Ownership teams collect new Requirements, Risks, and Problems, they start to analyze what they believe should go into the next Release. The amount of things that get addressed by the Release and the timeframe for delivery usually get impacted by the severity/criticality of the release.
Now, when you break down the possible permutations that a Software developer can actually deal with for a Release (I'm using SW development as the example because it's very common and typically covers the most complex permutations), there are really only "two" combinations...
1) Release the "whole" Product version (ITIL's "Full" Release). In this paradigm, the entire Product Version is packaged, as a whole, and distributed, in such a way that it will replace the entire previous version that exists on the target that will be rebuilt by the new Release (Product Version).
2) Release a "piece" of the Product version. (unfortunately, "both", ITIL's Delta and ITIL's Package Releases). In this paradigm, only a "piece" of the Product Version is packaged and sent. This could be as small as a single source file to as large as multiple preconstructed modules and libraries.
In either case, there are two forms of upgrade on the target system(s) that run(s) the Product. The first requires a rebuilt of all or part of the Product. The second is a complete binary "swap". The Product Management teams will typically dictate which is most appropriate and why.
Anyhow, please understand that ITIL's definition of Delta and Package Releases is confusing to most Product Development teams.
You'd do best to be wary of how you implement such terminology, because you can cause some serious conflict with your Product Management/Development teams.
Anyhow, I hope this helps.
Frank _________________ [Edited by Admin to remove link]
Joined: Jan 12, 2007 Posts: 48 Location: Warsaw, Poland
Posted: Tue Feb 27, 2007 1:20 am Post subject:
The Package Release is actually on exactly opposite side of the Full Release then the Delta Release. Package Release is the Package of Releases.
It is used when we are versionning the CI set independently and we want to force the specific change to be made concurrently.
We have the CRM system which we want to upgrade. This system uses the database engine that does not need to be upgraded on every CRM system upgrade especially since other systems also use this engine. We have also the complete desktop installation. Then we have 3 Releases:
- CRM upgrade (Delta Release)
- Database engine upgrade (Delta Release)
- Desktop Installation (Full Release)
We have decided that all 3 Releases need to be done concurrently. Then we create the Package Release, which contains all 3 releases. This gives us confidence that these 3 changes will be done at the same time. _________________ Krzysztof (Chris) Baczkiewicz
IT Standards Support
Joined: Sep 16, 2006 Posts: 3591 Location: London, UK
Posted: Tue Feb 27, 2007 7:55 am Post subject:
Please realize that most companies using ITIL are not software development houses. These companies use Release Change and COnfiguration to update operating systems and applications to the most recent versions.
So the poorly written ( I agree) Release mgmt piece in ITIL v2 is sufficient for that
If the company produces its own software and uses it inhouse with periodic updates, I would expect there to be application development policies and procedures which deal with the dev, test and live environment
The only one which ITIL really cares about is the finished one going out to the production world
I think she is concerned with the non-software production style of release mgmt not software production. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum