Background
There has been a lot of confusion, and a lot of us talking past each other regarding update set management, and how the platform limitations with regard to update set management apply to a 'best practices' SDLC process. Many team members have worked with other projects on platforms where rolling back an environment to a previous known state is trivial and quick.
For example, a code base managed by SVN has a versioning process, where it's easy and fast to apply a particular revision of code to a TEST environment, and you have successfully rolled back to a place before the delta to the code that caused a particular defect.
ServiceNow primitives for managing update sets
Update Sets are the molecules of ServiceNow release management. They contain one or more Customer Updates, which are the atoms of release management. Customer Updates are the smallest, indivisible unit for release management.
Recommended ServiceNow best practice (source wiki) is that Update sets are kept 'fairly small'. This is done so that it's easy to isolate changes to a particular context, and it back out a particular incorrect Customer Update from an otherwise correct Update Set.
Our own Yale processes is that we name update sets for the Date they were created, with the name of the Author, with a description that contains the Requirement number, as well as Defect number if applicable, along with a description of the work contained in the update set.
When an Update Set is In Progress, changes to the platform by that Author are captured in that Update Set. Unit testing is performed in place by the Author, and when the work is completed, the Update Set is set to state Complete.
Sometimes an Update Set is fully developed, and set to state Complete, but for certain reasons the code should be abandoned. An example would be the customer replaced their process or product and will never need the code that was developed. In this case, we would set the Update Set to Ignore. Update Sets with Ignore status are ineligible to be promoted to higher environments.
For reasons that should soon become clear, a Closed Update Set should never be re-opened and modified. Instead, if the code is incomplete or otherwise needs to be modified, a new Update Set should be completed that modifies whatever elements of the first Update Set that need to be corrected.
Merging update sets
Recall that Update Sets contain one or more Customer Updates. It is possible to merge related Update Sets. The merged Update Set contains all the Customer Updates previously contained in the individual Update Sets that were merged. The previous Update Sets still remain listed, but they contain no Customer Updates, and they are basically useless at that point. Official best practice is that after a Merge, the Update Sets that are now empty should be set to Ignore. There is no such thing as an Undo Merge operation. If a mistake is found after a merge, we would need to create a new Update Set in DEV, fix the issue, and when the issue is known resolved, merge that Update Set with the other Update Set.
Because in the earlier platforms of ServiceNow the Merge feature wasn't always perfect, Yale has not Merged Update Sets in the past. We have heard that Dublin resolves the previous issues, although there is still no Undo Merge feature. Allen from ServiceNow has suggested that Yale consider using Merge, and that we Merge in TEST environment, after testing is complete. When Allen gave that advice, he was under the impression that we were performing UAT in the TEST environment, so we should ask the question again after fully clarifying the way in which the meaning of the TEST environment has changed.
Advancing code from DEV to higher environments
When an Update Set is Complete, it becomes eligible to be promoted (deployed) to other environments. Update Sets in state Ignore or In Progress are not eligible to be promoted.
A person with Administrator access in the higher environment will run the "Update Source" feature. Then the feature "Retrieve Completed Update Sets" actually syncs the completed code repository with the local copy. This step does not actually commit the code to the higher environment, it just provides a local copy so that future code commits are using that local copy.
For this reason, and other reasons, we never re-open a Closed Update Set. Once an Update Set has been Closed, it becomes eligible for promotion to higher environments, and if we change the meaning of a previously closed Update Set, we may create a release management nightmare, where an Update Set in one environment doesn't do the same thing as the same-name update set in a different environment.
Previewing an Update Set
After new Update Sets have been loaded to a higher environment, those Update Sets are viewable in the Retrieved Update Sets view. All new Update Sets, and possibly other Update Sets previously loaded, will be in state Loaded. Using the release management process it should be clear to the Administrator which code should be applied, and in which apply order.
When applying multiple pieces of code to a single configuration element in ServiceNow, whichever code is applied most recently is the code that 'wins'. This means that apply order is an essential consideration in release planning. This is also why it is proper to often leave code in place when a defect is found, and apply a new Update Set which applies a fix to just the broken portion of code. In these considerations, we would have at least two pieces of code that applied to the particular defective element. We want the fix to 'win', so we need to be certain that the apply order is recorded and followed. We ensure this apply order through our Update Set naming convention, which is date-based. We also apply order through are Description conventions, where we apply a Requirement number (and a Defect number in the case of defects) as well as a description of the change made in the Update Set.
To Preview an Update Set, choose the Update Set from the Retrieved Update Sets view, and then click "Preview Update Set". A series of screens will indicate progress, and there will then be a screen to review the status of the Update. Often times a report will indicate that the Update Set contained change elements that modify an existing element, and you will be asked to confirm the change.