What are the possible errors that can happen while transferring update sets from one instance into another?

[shrpaul]

I have two Jakarta instances one is the dev and the other is prod.

Initially, I have worked on two update sets interchangeably. So before transferring the update sets into the prod both the update sets were merged together. The update sets contained reports and 2 dashboards with different access levels. When the merged update set was transferred into prod there were around 400 odd errors. What could be the possible type of that had shown up?

[Ian Mildon · Accepted solution]

To paraphrase from the Docs site:

The most recent change for each object is moved from the original sets to the new set. Only changes that are not merged into the new set remain in the original sets. A message indicates how many updates were moved and how many were skipped. For example, if both update sets modify the Incident form, only the most recent change is moved to the new update set. The other modification remains in its original update set to provide a record of the changes that were not moved.

[shrpaul]

Thankyou Ian, this was very helpful. Now I understand that both my update sets have only the old updates.

[manali harmalka]

Hi Sharpaul,

These are best practices with update sets :

• 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)

You can refer below link 

Discussion - Update sets - Some useful tips and best practices

Hit Helpful or Correct answer as per response given.

Regards,

Manali H