Examples of Release

[Camelia]

I know the 3 types of release are Full, Delta and Package but can anyone please give me a couple of examples of each. Many Thanks!!!

[Guerino1]

Hello Camelia,

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.

My Best,

Frank
_________________
[Edited by Admin to remove link]

[Cekir]

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.
For example:
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
Eracent

[UKVIKING]

Frank

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

[Camelia]

Thanks guys for your replies.