Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: MHutton
New Today: 57
New Yesterday: 87
Overall: 139323

People Online:
Visitors: 48
Members: 1
Total: 49 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Release Identification
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Release Identification

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
Debbie
Newbie
Newbie


Joined: Jan 23, 2006
Posts: 13
Location: San Francisco, CA

PostPosted: Fri Nov 17, 2006 4:48 am    Post subject: Release Identification Reply with quote

We are a company of about 200,000 and I’m researching how to handle Enterprise releases and release identification. Our plan is to bundle several desperate application changes into pre-determined releases times and release windows. Currently we are looking at having 1 On-cycle release a month. These would be our major releases. We would have 3 Off-cycles—these would be our minors and deltas. Anything else would be an emergency. Basically we are setting the schedule and release windows as to when applications can be released into the live environment. Is this common or is it left up to each individual system to determine their release times in the FSC? Is it manageable?

The second question is regarding Release Identification. ITIL suggest the following: Major equals V1, V2, V3, Etc. Minor equals 1.1, 1.2, etc. and emergency fixes as 1.1.1, 1.1.2, etc. – with the application identifier prior to each release number. For example Payroll_ System V1, Payroll_System V1.2, etc. This looks like the versioning is specific to the application change rather than the Enterprise Release itself. How would you version a Enterprise Release for all these application changes? Use a date?

The more I know about Release Management the more I am confused. Rolling Eyes
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Wed Nov 22, 2006 12:34 pm    Post subject: Re: Release Identification Reply with quote

Hi Debbie,

Please see my responses, embedded below...

Debbie wrote:
We are a company of about 200,000 and I’m researching how to handle Enterprise releases and release identification. Our plan is to bundle several desperate application changes into pre-determined releases times and release windows. Currently we are looking at having 1 On-cycle release a month. These would be our major releases. We would have 3 Off-cycles—these would be our minors and deltas. Anything else would be an emergency. Basically we are setting the schedule and release windows as to when applications can be released into the live environment. Is this common or is it left up to each individual system to determine their release times in the FSC? Is it manageable?


This is really up to your enterprise and what is acceptable to them. Setting structured release windows is very common for larger enterprises, where there are many different product releases and changes going into an environment. You may want to also think about structuring such windows for non-production environments, too, such as Systems Integration Testing, User Acceptance Testing, etc.

As far as determining "times", it usually comes down to what impacts the business units the least. This includes symptomitic impact of indirect business units that might be sharing things like common infrastructure, data, etc.

Quote:
The second question is regarding Release Identification. ITIL suggest the following: Major equals V1, V2, V3, Etc. Minor equals 1.1, 1.2, etc. and emergency fixes as 1.1.1, 1.1.2, etc. – with the application identifier prior to each release number. For example Payroll_ System V1, Payroll_System V1.2, etc. This looks like the versioning is specific to the application change rather than the Enterprise Release itself. How would you version a Enterprise Release for all these application changes? Use a date?


Again, this is up to an enterprise. We definitely abide by the 3 segment approach:

<Major_Indicator>.<Medium_Indicator>.<Minor_Indicator> (Ex: 3.13.2).

However, we do not put the applciation identifier in the release label. Stakeholders can find that information from the DSL and from the CMDB. However, there's nothing that says including the application identifier is wrong. What matter is that it is clear and consistent for your enterprise.

Quote:
The more I know about Release Management the more I am confused.


This is common when using ITIL Release Management as a baseline. It is very weak and, as mentioned multiple times in other posts, is very inconsistent with traditional defintions of Release Management.

I hope this helps.

Best Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Marcel
Senior Itiler


Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Wed Nov 22, 2006 11:35 pm    Post subject: Reply with quote

Release Mgmt in ITIL is somewhat limited to a "put into production" perspective and does not address the software development life-cycle. This is because ITIL's focus is on the technical part (infrastructure) of IT management.

You may want to look into ITIL's younger brother: the Application Services Library (ASL), which is being promoted by the ASL Foundation. This organization is somewhat like itSMF.
Back to top
View user's profile
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Thu Nov 23, 2006 12:50 am    Post subject: Reply with quote

Agree with Frank and Marcel. Release Management is actually a sub-process of Change Management. You need to look at them as a whole, and understand that the project of releasing a software update is a different process than preparing the software itself.

You let the developers play in the sand box. As soon as possible, an RFC needs to be raised and the Change Mgr in charge of that RFC will coordinate the timing and conditions for the release. A process to release the software needs to be developed, tested, etc... etc... etc...

If you take Release Mgt as a part of Change Mgt, then usually it gets a little less confusing... Hope this helps...
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
Debbie
Newbie
Newbie


Joined: Jan 23, 2006
Posts: 13
Location: San Francisco, CA

PostPosted: Thu Nov 23, 2006 2:30 am    Post subject: Release Identification Reply with quote

Thank you all very much you have been very helpful. As of now we are going to use the 3 segment approach with a date appended.

Fabien wrote:

You need to look at them as a whole, and understand that the project of releasing a software update is a different process than preparing the software itself.

You are so right! I was having a difficult in seperating the two and your comments have helped.

Thanks again!
Debbie
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Mon Nov 27, 2006 3:51 pm    Post subject: Reply with quote

Hi Fabien,

I wanted to quickly address a statement you made...

Fabien wrote:
Agree with Frank and Marcel. Release Management is actually a sub-process of Change Management.


Actually, this is innacurate and I apologize for pointing it out, as I don't wish to put us in a position of conflict. Release Management is actually a super-process of Change Management. A Release contains one or more Changes that get deployed to target environments. This is why Products are versioned "Release X.Y.Z", with Release Notes that highlight the Changes contained, within the Release, and the Requirements, Defects, and Risks that drove the Changes.

I've mentioned this multiple times and I can't stress it enough, ITIL is very poor at its attempt of Release Management. If you implement ITIL Rel. Mgmt. in your enterprise, you will have direct conflict with what the Product Management, Development, and Engineering teams are doing. Since they typically own all products and their strategy, they almost will ultimately get their way, putting them in a position to view your ITIL implementation negatively.

Quote:
You let the developers play in the sand box. As soon as possible, an RFC needs to be raised and the Change Mgr in charge of that RFC will coordinate the timing and conditions for the release. A process to release the software needs to be developed, tested, etc... etc... etc...


Actually, RFCs are accumulated by the Product Management teams. They make decisions as to which RFCs they wish to roll into their Product Releases. After a period of development, they will solidify which RFCs will stay in the Release for deployment. This is because there are a few that won't stay in the Release and may possibly be backed out and/or moved into another Release. When the Release and everything it will contain is stable (typically before Release to UAT), a Request for Release should be processed (not something ITIL covers, at all).

In each phase of moving the Product Release through its environments, a Request for Release should be scheduled. This will populate your Forward Schedule of Releases with this new Release. As the Release moves into an environment, all embedded RFCs should be reviewed for impact to the new environment.

If you make the Release a sub-process of your Change Management process, you will have some ugly issues.

Quote:
If you take Release Mgt as a part of Change Mgt, then usually it gets a little less confusing... Hope this helps...


Again, this is reversed and will cause problems and conflict in your enterprise if you implement it this way.

I hope this helps.
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Tue Nov 28, 2006 12:18 am    Post subject: Reply with quote

Frank, you are adressing the unique case of a software company. If your software release is the launch of a product, there are numerous other processes that need to be involved and in that case, the Change Manager would likely be the Product Manager. There is nothing in ITIL that says that there can only be one Change Manager in your organization.

In the Config/Change/Release cluster, the Change Manager is the one making the decisions. Release Management's role is to carry them out.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
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

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops © 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest © 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.