Should we merge the update sets before

Yuri Yoshinami
Tera Contributor

‎03-19-2020 12:48 AM

Hi, all the experts of the servicenow,

I just want to confirm the right way of transferring the update sets.

Could you tell me both of the answers?

Q1) Is it better to merge the completed update sets on the dev instance before retrieving the update set from dev instance?

Q2) If there is the updates whose target are the same with differences update sets, is it better to merge the update sets?

 

I was transferring the update sets from the dev instance to prod instance with retrieving the update set, whose status are completed on the dev instance.

When the team were developing, we have created the update sets like, knowledge_sprint1, knowledge_sprint2, knowledge_sprint3, Incident_sprint1, Incident_sprint2, Incident_sprint3. and so on. It means when the customer requirements changed after sprint1 we have changed the setting on knowledge_sprint2, and all the new updates will be merged on the update set: "XXX__sprint3"

Since the doc says "You cannot "unmerge" the update sets once they have been merged", I was looking the way not to merge any of the update sets. 

 

https://docs.servicenow.com/bundle/orlando-application-development/page/build/system-update-sets/tas...

 

 

 

 

 

 

 

 

 

0 Helpfuls
  • 2,350 Views
5 REPLIES 5

Vishakha
Mega Guru

‎03-19-2020 01:15 AM

Hi Yuri,

 

Best Practices.

 

  • Don't keep update sets open which will span upgrades.
  • No open update sets during cloning. All updates promoted to PROD before cloning.
  • Ensure that all instances are on the same version
  • All instances should be clones of Production
  • Identify common path for update sets to move to/from
    • good practice: dev > QA > prod
    • bad practice: dev > < QA > prod
  • Use meaningful names and descriptions in your update sets
  • Be cognizant of what will and will not be captured in an update set
  • MAKE SURE YOUR UPDATE SET IS ACTIVE!!!
  • DO not delete any update sets. If you have merged update sets, and they have migrated successfully, you can delete them to save confusion later.
  • Do not touch 'Default' update set, its properties or values.
  • Don't delete anything from 'Default' update set. It may save your bacon!
  • Never modify the 'update set' field value in a customer update set. (i.e. do not manually move changes between update sets). Unless there is no alternative.
  • Only 'complete' an update set when it's 100% complete
  • Commit update sets to QA in correct order. ie order they were created and by application.
  • Commit update sets to PROD   in correct order. ie order they were committed in QA IF QA testing is agreeable.

 
 

  • If committed update set has problem, complete your fixes in another update set (in dev) and promote fix with the correct naming convention ie meaningful.
  • promote fixes in the same way as normal changes. See "Life-cycle of an update set
  • Know who is doing what
    • To prevent 'stepping on another admin's toes,'
    • Communicate between admins/developers
  • Don't use other developer update sets, create your own
  • Consider merging update sets prior to committing. According to ServiceNow, Last update wins!
  • Allow for an emergency change process to quickly promote an emergency fix through DEV>QA>PROD
  • Merge completed update sets that you are going to promote together, and delete the original sets that were merged. (If you plan to use merged update sets)
  • Always run preview just prior to committing an update set.
  • Create FIX update sets to promote any changes needed from QA testing
  • Set completed local update sets in production to a state of "ignore" so they are not reapplied after cloning production over DEV and TEST.   I don't think you have to do this any more, but I haven't tested it yet!
  • Use one update set for a workflow; do not use multiple update sets to transfer a workflow change.  
  • Publish the workflow before you close the update set.
  • Schedule updates after hours — time of least end user impact (example of when user was updating an RFC)

 

Mark Correct & Helpful if this solves your issue.

Thanks,

Vishakha Pradhan 

0 Helpfuls

Geetanjali Khy2
Mega Guru

‎03-19-2020 01:33 AM

Hi Yuri,

You can merge that update set, but merging the update set is not good practice. It will create one new update set and it will ignore all 3 update sets.

 

All possible ways to move update set to higher instance:

 

Either you can move all 3 update sets to higher instance

 

OR

 

You can merge and move. But that is not good practice.

 

OR

 

- You can create one parent update set.

- Add all 3 child update sets to that parent update set. 

- And move the parent update set to production.

 


Kindly mark the answer as correct and helpful if this answers your question.

Thank You.

 

Regards,

Geetanjali Khyale

asifnoor
Kilo Patron

‎03-19-2020 01:39 AM

Hi,

you shall merge update sets which all belong to 1 specific feature or module. In dev there could be multiple update sets like completing a feature and then fixing bugs and again another update set more fixes/changes.

In this case, before you transfer this to production, in your staging instance, merge all the update sets and then transfer 1 single update set to production.

The merging shall happen in staging instance and not in dev.

Kindly mark the comment as a correct answer and helpful if it helps to solve your problem.

Regards,
Asif
2020 ServiceNow Community MVP

0 Helpfuls