- Know what is happening and who is doing what
- To prevent ‘stepping on another team-members/developers/admin’s toes,’
- Communicate with team-members before talking to admins
- Use meaningful “Names” and “Descriptions” for your Update-sets. Don’t use other developer Update-Sets, create your own.
- Naming conventions:
- Update sets should have relevant naming conventions like [Team Name][Sprint Number][Application Name][Initials][Date][Version] (Choice of your own to distinguish your team’s update set from other teams pretty quick)
- Suggested Naming convention:
- For immediate fixes, suggested naming is update set name + FIX (like ************-FIX). Fixes would be for the same day committed applications.
- For Emergency Change; update set name + EChg (like *****************-EChg). Emergency Changes would be fixes for issues found later. This would be mostly for Rollbacks.
- Your code can have a template like the following details
*****ServiceNow will have the records, but when cloning the created by & updated by might change to “Admin” user id
- User Proper variable names, Indentation and Comments. (Do not use variable names like a,b,c,i,j,k…and so on.)
- Write readable yet efficient code
- Do not touch ‘Default’ Update-Set, its properties or values. Don’t delete anything from ‘Default’ update set.
- MAKE SURE YOUR UPDATE SET IS ACTIVE!!! (So you don’t lose your updates while working on your task)
- Be cognizant of what will and will not be captured in an update set (like Scheduled Jobs doesn’t get captured in Update-Sets). Sometimes you might need to Force record to update sets.
- Consider merging Update-Sets prior to committing. According to ServiceNow, Last update wins!
- DO not delete any update sets. If you don’t need any Update-Set please mark them “Ignore”. (If you have to delete Update-Sets, please confirm that none of these changes impact changes in another update set)
- 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.
- Common path for Update-Sets to move to/from
- Good practice: Dev > UAT > Prod
- Bad practice: Dev > < UAT > Prod (Moving between Dev and UAT)
- Commit Update-Sets to UAT in correct order. i.e. order they were created and by application. (For instance first commit Update-Set1 then Update-Set2)
- Commit Update-Sets to PROD in correct order. i.e. order they were committed in UAT IF UAT testing is agreeable.
- Always run preview just prior to committing an Update-Set.
- Promote fixes in the same way as normal changes. Create FIX Update-Sets to promote any changes needed from QA testing. If committed Update-Set has problem, complete your fixes in another Update-Set (in Dev) and promote fix with the correct naming convention i.e. meaningful. Allow for an emergency change process to quickly promote an emergency fix through DEV>UAT>PROD.
- Do Not Make “on the fly” changes on UAT/PROD. This ‘breaks’ future update sets.
THE LIFE-CYCLE OF AN UPDATE-SET
- Play, test, break, compare, prepare…do all this in Sandbox.
- Create update set in DEV
- Create / recreate your changes in DEV
- Capture Customizations
- Compare/Merge as needed
- Mark completed
- Test changes in DEV
- Retrieve update set in UAT
- Test changes in UAT
- Retrieve update set in PROD
- All instances (Sandbox, Dev, UAT, Prod) are on the same version
- No open Update-Sets during cloning. All updates should either be promoted to PROD or saved before cloning.
- Admins should send out Email to people who have open Update-Sets with the cloning date of Dev/UAT
- Plan for working Update-Sets during cloning. Mark them Complete -> Save your copy -> Once cloning completed, Reupload to Dev/UAT Instance -> Change to InProgress -> Mark update-set as current -> Resume working on your stuff.
WORKING WITH WORKFLOWS
- 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.
- 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!
Duplicate 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.