Release Record

General discussion on all aspects of the IT Infrastructure Library (ITIL)
Post Reply
User avatar
ChasingSleep
ITIL Expert
ITIL Expert
Posts: 78
Joined: Mon Nov 17, 2008 7:00 pm

Tue Jul 28, 2009 1:16 pm



User avatar
SwissTony
ITIL Expert
ITIL Expert
Posts: 118
Joined: Wed Feb 25, 2009 7:00 pm
Location: Geneva

Mon Aug 03, 2009 5:05 pm

User avatar
ChasingSleep
ITIL Expert
ITIL Expert
Posts: 78
Joined: Mon Nov 17, 2008 7:00 pm

Thu Aug 06, 2009 8:34 am

User avatar
Fabien
ITIL Expert
ITIL Expert
Posts: 207
Joined: Mon Sep 26, 2005 8:00 pm
Contact:

Fri Sep 25, 2009 11:15 pm

Actually, a release sort of is a CI but that's not important in all honesty. It's a sideshow. What matters is:

1) Release & Config need to work hand in hand. If config needs a record in the CMDB, negotiate. Maybe you want a CM Plan as part of your release documentation anyway. It doesn't need to be cut & dry. Depending on what system you use, it could make a whole lot of sense to have all records in the same place.

2) Make the difference between a release and a deployment. The release is the 'thing' while the deployment is the action of migrating the thing to an environment. Make sure that you capture that somewhere because it drives many things...

3) A Release can have multiple deployments, contain multiple RFCs, and deploy multiple CIs (not necessarily the same in each deployments). Now, if you have to provide traceability in your records, think about the implications of that. The closer you get to bridging your CMDB with your Change mgt system, the better off you will be.

Here are a few ideas to explore:

1) You need to have a Release Verification process that will guarantees that only approved changes are being deployed and that all changes have been tested. You definitely want your deployment record to be linked to RFCs.

2) You need to allow Configuration Mgt to run a pre-deployment audit of the CIs that are about to be deployed. So, somehow, you need CIs attached to your deployments (whether directly, or indirectly through the changes)

3) I use Release records to connect my deployment records so when I plan a project, I can schedule and consolidate the plans of all test deployments, my main production deployment(s) and any further test & production deployments.

4) You need to allow for a correlation between incidents and releases because it is one of the most important metrics. One of Release's main objective is to provide a controlled way of executing changes so as to limit the risks and disruptions to the business. All these things are connected.

5) Think about your end-to-end control over the assets to deploy, and use Configuration Mgt for that. The change approved = change built = change tested = change deployed. The chain of custody of the change through the lifecycle matters a lot. You need a DML and version control for most of that, and that comes from Config.

BTW. Release is hard. It just is. I have never found anything easy about it. But it is exciting. Hope this helps...
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
User avatar
DYbeach
ITIL Expert
ITIL Expert
Posts: 413
Joined: Sat May 24, 2008 8:00 pm
Location: Sydney, Australia

Sun Sep 27, 2009 8:17 pm

That is a very helpful answer, Fabien, thanks for your time and effort
DYbeach
ITIL V3 Release, Control & Validation,
ITIL V3 Operation SUpport & Analysis
PMI CAPM (R)

"In times of universal deceit, telling the truth will be a revolutionary act." George Orwell
User avatar
ChasingSleep
ITIL Expert
ITIL Expert
Posts: 78
Joined: Mon Nov 17, 2008 7:00 pm

Mon Sep 28, 2009 9:49 am

Excellent!

Thank you very much Fabien. Indeed, it is a hard path. Especially when you consider the whole picture, with all the interfaces to other process.

We are still on the road here. I will post regularly our success (and failures).

Cheers !
Post Reply