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?

[SANDEEP DUTTA]

Hi @Sherwin G ,

This Scenario which you highlighted is a complete developer Hygene issue. the developers may work on multiple stories at once, and if they forget to switch update sets or isolate changes, they risk contaminating one update set with unrelated changes. , as per my experience i would be doing below :

1. Create a dedicated update set per story/ticket with a correct naming covention.

2.  I would review update sets manually before moving to lower instaces to higher, this would help me to Remove unrelated entries.

3.  I would assign a particular role like  release manager (Yourself) can commit update sets into TEST/PROD.

[Ankur Bawiskar]

@Sherwin G 

the only thing which developer can do is

1) review each of the update set and if update is not required then move to Default update set

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Dr Atul G- LNG]

Hi @Sherwin G 

It looks like governance is missing here. As a Release Manager, you need to establish the best practices, rules, and policies around this. Make sure that before a story moves to the next state, the correct update set is mapped. Create a task at the story level to ensure these update set/development checks are done, so that no unwanted update sets are included in the release.

Follow the practice that every update set should be tied to a specific story. If not required, avoid merging or creating batches. I know this may feel strict, but if you include these points at the story level, it becomes much easier to manage changes.

[Sherwin G]

Hi All,

Thanks for your advises and I do agree there is a bit of developer's responsibility in this situation (which we are trying to govern at the same time).

I am more looking into ways for the release manager to 'easily' identify if the changes included in the update set is not contaminated. So far, I can't find any solution from the forums on this.

For example, if I am handed 10 different update set containing more or less 10-20 updates in each of them, how can one figure out or be sure that they are 100% legitimate changes related to the story/update set?