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?

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.

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.

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

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.

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