Release or Change first

[ITILAddict]

Hi,

I m still fighting with those 2 processes It seems i keep getting contradictory information from my reading on the subject.
If my project is to add new fonctionnality to a web application, which involves upgrading the server.
Do i go to change management first ?
1 - split the project into 3 or 4 RFC
2 - wait for the CAB approuval
3 - go through the release management process

Or do i go to RM first ?
1 - dev do their part / production do their part (on the machine)
2 - test application...
3 - Validation
4 - Write RFCs for the software and hardware part of the project
5 - wait for approuval
6 - push into live environment

Thanks for your help ...i m trying to work on the workflow and each time i come up with smthg it doesn't seems right

[stephensan]

I've just come off the foundation course during which I asked more or less the same question.

The answer I was given by the tutor is that it's Change > Release, an answer which was backed up by the dummy exam papers.

The example given during the course was similar to your second scenerio.

Hope this helps

[itilimp]

My take is:

At the initial stage that it is identified that someone wants additional functionality adding to the web app, this is raised in incident management as a service request and then logged as a RFC under change management.

The scoping and requirements etc. would be part of the rfc process and once it reaches the RFC implementation stage this triggers the release process for building. Once the build is complete it feeds back into the change for approval, confirmation of backout plans etc. before going back to release for implementation in live environment.
RFC gets closed, service request gets closed (and hopefully there aren't lots of new incidents which require the backout plan!).


Having said all that, I don't work in a development environment so it may be that I'm missing something

[Ed]

Hi itilimp

You are spot on with what you are saying, All I can add, is to say the Development will only be involved if new code is required to give the functionality that is being requested, as opposed to having an Admistrator 'switch on' the functionality. 'Phew'

Regards

Ed

[itilimp]

Thanks for that Ed. I view release management as one of my weakest knowledge areas in ITIL core at the moment - have to work on that

[Guerino1]

Hello all,

I'll give you what I see with my customers as well as what has been a part of SW development for the last few decades.

When it comes to software or hardware, a "Release" is a new controlled version of a "Product" that must be implemented and delivered. It is composed of one or more "Changes".

There are two philosophies:

1) Once a Release is closed, create a new one and start to apply Changes to it, and
2) If a Release is open, some Changes are benign enough to role out, independently (almost like a Delta Release). Even so, for every new Change that is applied to a Release, the Release version or some identifier gets modified to ensure that someone can checkpoint the Release to specific states in time.

Releases and/or Changes are driven by three things:

- Problems (such as Defects/Bugs)
- Risks (the need to avoid future Incidents), and
- Requirements (typically for new features or a modification to an existing feature or state)

NOTE: Incidents, typically do not drive Releases or Changes, as they are usually direct drivers for Problems, Risks, and new Requirements.

ITIL has some obvious flaws in in that the creators did not think the entire data model, through. As a result, a point of confusion is that ITIL sometimes allows an RFC to act like a "Requirement to modify something that exists". NOTE: Another point of confusion is that it sometimes allows an RFC to act as a Service Request, where someone fills out a Request for Change to have work done but that's another conversation.

Anyhow, a Release is usually created "before" the application of Changes to the Release. Or, the Release already exists and is open (implying that it was created before the application of Changes.

Think of it this way, you are "versioning" a Product and constantly tracking versions so that you can checkpoint states of the Product at specific times and have history that allows you to reconstruct a specific Release at a very specific point in time.

For infrastructure, it's a bit vaguer, as most Engineers and Operations support staff aren't used to thinking this way. But, if you think about it, it is the exact same thing. If I want to manage a Product called a "Data Center X", I can control it's versions by understanding what Changes I grouped together into a specific Release. I possibly allow Releases & Changes every Thursday night and would have 52 controlled Releases over the course of the year. If I apply an expedited or emergency Change in the middle of the week, it is typically being applied to an open Release or version of the Data Center X Product that I am managing. If done properly, there is a "Data Center X" Product Owner, one or more Release Managers, one or more Change Managers, etc.

Release Management is the process of identifying and managing one or more Releases through its/their lifecycle and includes the logistics of managing which Changes are being applied to the Release and being rolled out as part of the Release. Rel. Mgmt. includes the logistics associated with planning what goes into the Release with the Product Owner, Dev Mgr. and other critical stakeholders. It is responsible for managing and ensuring that the builds and deployments are stable and repeatable. It is also responsible for ensuring that the builds are tested in each and every environment (not to say that it actually does the testing), etc.

Changes are a more "granular" concept. As stated before, a Release is composed of Changes.

If done correctly, A Request for Change (RFC) is really nothing more than a marker to show what "is" changing in the Release. Requirements, Problems, and Risks should already be vetted out and will drive the RFCs, where you can have:

One-to-One Relationships,
One-to-Many Relationships,
Many-to-One Relationships,
Many-to-Many Relationships.

If done properly, the implementation of one or more RFCs as Changes, within a Release, allows complete and visible traceability. You can trace a Change back to a specific Release & Product. You can trace a Change back to its original drivers (Problems, Risks, & Requirements). You can also see what "Parallel Changes" a specific Change is either implicitly or explicitly dependent upon.

Anyhow, I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]

[blamblam]

I would definitely start with Change Management. It is the protector of the production environment and a customer-facing process. I would also implement Configuration Management ahead of a mature Release Management process as well.

I happen to be working with a client at the moment who have developed Release Management ahead of Change Management and while they are now very good at handling Changes through the various environments, they have no visibility of the volume of Change in the pipeline. They have issues with categorisation, prioritisation, lead-times, communication and approvals - all things managed by the Change Management process.

[Fabien]

While I agree that you start with Change Management without a doubt, my reasoning is a little different. You see, Release Management is not about software development. The question is framed around whether you do App Dev before managing the change. Those should be done pretty much at the same time to be effective. Release Management only comes afterwards, when the product needs to move from the sand box into the production environment.

App Dev largely occurs outside of the Service framework. It is important to not confuse the Build ITIL sub-process of Release Management with a software build. Release Management refers to building the release package, not building the application.

That being said, it is of course practical and a good idea to involve operations before starting the project in the first place as the CAB will be able to define parameters for the Dev team. But in quite some cases, the customer talks to app dev independently from Ops.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek

[Ziad]

Application Development is not part of, nor governed by, Release Management.
Release Management will do the testing in a development environment, move the application to staging, prepare a roll-back plan then move the application to production.
All this should be under the control of Change Management. Therefore, in my opinion, the sequence in your case is Change Management then Release Management.

Regards,
Z!