Need assistance with releasing update sets across instances

[Sherwin G]

Hi Team,

I am acting upon the role of a Release manager in our team. And I have noticed an issue which has occurred multiple times now with our current release process.

The scenario is this:

• We package our update sets in our DEV instance before we release them to TEST and/or PROD.
• The issue that we faced is that in some cases, some 'unwanted' updates gets included in one of the packaged update sets which then may/may not impact the end users in PROD.
• A simple example is when the developer is working on multiple changes and one update was included in the set which is not supposed to be release yet. This is typically not captured during UAT since the supposedly update is not part of the test case (let say that update was for a very different form in the system).

Do you guys have some advise on how to mitigate this scenario?

[JackieZhang]

In my previous work，I will go though the updates by developer one by one.

1. first to check recently changed in default updates for this developer to avoid missing update.

2. check the update which in update set created by this developer to avoid 'unwanted'.

BTW, it is hard to make 100% no missing or no 'unwanted.'

[JackieZhang]

HI  Sherwin G,

I think it is common issue for missed or  'unwanted'  when you release package to UAT/PROD.

We need to prepare a check list before your release:

1.Prepare the release document before release such as updates,xml, fixed script, scheduled job and manual update steps, backout plan etc.

2. Check the updates belong to the update set is in same scope.

3. Open the review meeting with each developer for check where the update is needed  for release or there is any update or update sets missed before release.

[Sandeep Rajput]

@Sherwin G In an agile model, the best way to avoid contamination of the update sets is to tie update sets with stories.

In our development process, during a sprint, a developer needs to go to the production instance to set a story to 'Work in progress' state, once done, this story gets synced to our development instance. On the dev instance, developer can create update set via 'Create update set' UI Action and they can work on the story. 

At any given time, our devs need to complete the existing story first and they can move to other stories. Each of these stories have specific releases assigned to them. 

During the release only the stories with an approved release go for deployment.

As shared by others, you need to have a Governance model in place and everyone in the team need to strictly follow this model to avoid update set contaminations from unwanted changes. 

[Sandeep Rajput]

@Sherwin G Please consider marking the response an accepted solution if I addressed your question.

[Sherwin G]

Hi All,

At this stage, we have decided to incorporate a peer review in our release process. Though I don't know if it will help in our case. 

I have read and reviewed all your suggestions and am thankful for it. But given the fact that developers don't have the actual means of manually packaging their updates in an update set, I don't think it resolves the issue of having some 'unwanted' updates getting mixed up in an update set they are working on. We all know that ServiceNow captures every stroke/action we do in the application to the current active update set. So if the development work consists of more than 50 updates spanning across multiple components, how would a review truly help out?