Does a release record really mean bunde of changes ?

[RC19]

I am trying to understand the relationship between release record and change request record. I am thinking that in release management process (Ex: DPR) once UAT phase is completed, we create a change request from that release record, get all approvals and proceed for deployment and if any issues arise in that deployment, we can raise one more emergency CR and fix that issue. So around 1-2 change requests might be raised normally on release record.

But I heard from different people that Release record is a bundle of change requests. is it true? how is it possible? because if we are tagging multiple change requests to one release record and if some of them could not be completed then how will we track it in our release record/ process?

[Mark Manders]

It depends on your setup. 

In theory, the change is about when the changes are being applied and checks for any dependencies and takes care of approval of the changes being applied at a certain time.

The release contains the information about what is going to be released.

But I have seen them used both ways. Several teams with releases that all go live in one window, create one change, because the window is free, but also a several changes for different software/hardware that is all combined as one release, because they have been worked on like that.

Check out ReleaseOps (Zurich). It gives you a clear view of how ServiceNow can handle it. With most clients we create deployment records for each story/incident, which are combined into one release after they have been tested and approved and then the release creates a change which can even be auto approved if it doesn't contain updates to critical systems/applications/servers (or need CAB when they do).

[Dr Atul G- LNG]

Hi @RC19 

As a process consultant, I can say that a release is considered the bundle of changes, which means different changes for the same release can be grouped in one place. It is primarily for tracking purposes, so instead of going through individual change records, you can see everything deployed in a better-linked way. All items are recorded in one release, making it easier to track and review.

We are adding multiple changes in a release, and that is primarily for tracking. If one change fails, we need to either fix it, remove it in UAT, or create a fix for it.