Committed Update Set Not Actually Complete

[ssturde]

Help!! I committed a large update set this morning, it shows committed, but when I go to validate, more than half of the updates are missing. Any way to fix this? Do I need to delete the update set, reimport from test, and re-commit?

[Community Alums · Accepted solution]

Check the update set in the source environment and ensure that it contains everything it is supposed to.

If the update set in the source environment has everything:

You can export that update set as XML, and import it into the destination instance via Retrieved Update Sets.

Once you do that, you can preview and commit it.

You will get a "this record has a more recent update" error for all the items that went through with the first update set, You can either ignore these, or accept them all. It shouldn't make any difference since it's the same update you're applying.

If the update set in the source environment doesn't have everything:

You should look in other update sets and the "Default" update set to see where your updates went. Once you find them, you can either:

1. Move them into a new update set and apply them (risky)
2. Add each record that is missing into a new update set manually (time consuming)

Hope that helps.

[ssturde]

Thanx. I found out why it happened, which was a query collision from a service account that was pulling all fields from the table I was updating. This helped me clean up the mess from that.

[haseena ayesha]

Hi

Studevant,

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)

 
Common mistakes.

• Update sets are committed to QA, but not to PROD. All instances should be the same.
• Update sets are created, and deleted before use. Can you confirm that none of these changes impact changes in another update set?
• Users both working on the same application, especially workflows.
• Making "on the fly' changes in PROD. This 'breaks' future update sets.
• Leaving workflows checked out when you complete an update set.
• Cannot publish an workflow Set? I have found that if I am testing a workflow, a record may have the new workflow open. Close those records!

 
Workflow issues
Overview.Workflows are tracked in update sets differently from other records because the information is stored across multiple tables. Changes made to a Workflow Version are not added to the update set until the workflow is published, at which point the entire workflow is added into the update set. Avoiding Duplicate WorkflowsDuplicate workflow records may be created on the target instance if you use multiple update sets that do not include all of the intermediate changes. Changes may be missed if an intermediate update set is not applied to the target instance or if some changes were applied to the Default update set by mistake. To avoid duplicate workflows, ensure that every change is moved to the target source. Use the following practices for the best results:

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

Trick if you see duplicate workflows — de-activate/activate the newer workflow and the older version will disappear.  
ExampleFor example, duplicate records can occur in the following scenario:

1. A workflow is created and published in update set 1, which is moved to the target instance and applied.
2. The workflow is checked out, changed, and published in update set 2. This workflow is not moved to the target instance.
3. The workflow is checked out again, changed, and published in update set 3, which is moved to the target instance and applied.
4. This scenario results in duplicate published versions of the same workflow because the original workflow was marked as unpublished as part of update set 2, which was not moved.

1. Before starting the deployment disable the LDAP server to prevent users from logging in
2. Kill all active user sessions (including the prod MID server?) … the "do the deployment" part …
3. Re-enable LDAP server.

Additional Notes - from worthy contributors:

When you run a clone from prod to dev/test, the clone uses the previous day's backup, not a real-time snapshot of your prod environment. Therefore, if you complete and migrate your update sets to prod, then do the clone back to dev/test on the same day, your dev/test instances will not have the latest update sets in them and your instances will now be out of sync.

please go through bellow link,

Discussion - Update sets - Some useful tips and best practices

Thanks&Regards

Haseena.

                                                                                  PS: Hit like, Helpful or Correct depending on the impact of the response

[FIKRI BENBRAHIM]

Hello to you all,

   This best practice was very useful. Thank you very much.

Best regards

FIKRI BENBRAHIM Mohamed Jawad