Background
In July 2014, the ITSM team decided to postpone the development work originally scheduled for release April 2014. That work was tracked here:
Later in July 2014, the ITSM team decided to empty DEV instance of all work not created by Fruition as part of the Health Check Remediation work.
As such, we need to archive out large amounts of code. The supporting mechanism for ServiceNow is the XML export of update sets, and the subsequent XML import of those update sets.
http://wiki.servicenow.com/index.php?title=Saving_Customizations_in_a_Single_XML_File
About half of the code is what would have been the April / May / June 2014 release. As such, this code is completed, thoroughly tested, and UAT'd (twice). We would like to not save this work in a way that allows us to faithfully restore it at a later date.
Primitives
Applying update sets properly in this requires a few things working together:
- the update set exports themselves
- external information about the update sets:
- The appropriate apply order
- The status of the development work
- The status of any related testing
- The status of any related UAT
These are important for various reasons. Having the raw import sets doesn't do us as much good as you would expect. Most requirements, and even many defects are spread across multiple update sets. If those update sets are not applied in the appropriate order, the resulting changes will not represent those intended by the developer, or approved by the tester, or approved for release by the stakeholder.
How we get the apply order
The obvious way to do this is to go to the instance that contains the appropriate apply order, and then go to:
Retrieved Update Sets -> Filter by Committed > Sort by Committed date. This will give you a proper listing of the current update set list. However, you will have to know how to compare that against the floor set by the most recent clone down on that instance. For example, on July 21, 2014 TEST was cloned on April 17th, and anything before that is the floor from PROD. But manually having to know that is annoying. At any rate, with that knowledge, you could then export the list, and use that as your checklist for building a release plan for the next environment. Or in this case, a plan for properly applying code at a time and place in the future when we wish to restore any of these update sets.
A better way to get the apply order and automatically subtract out the floor is to use a script found here:
https://github.com/wwest4/ServiceNow/blob/master/ServiceNow/diff-instance.py
This script then outputs a nifty list of just the stuff we actually care about. If you run it on a unix command line, you can readily redirect the output to a flat file and hang onto it.
I have a few different lists like this with the appropriate apply orders for portions of START Replacement, as well as appropriate apply orders for the April 2014 release.
Finally, I will also need a dump from DEV of the Update Set table, before we clone over DEV. Made a file called update_set_listing_dev_2014-07-22.csv , attaching it up here until I have a better place.
The report of the disposition of various update sets
Backeberg made a report of the disposition of 280 update sets. This is nearly an exhaustive list. That list is stored on box, and also attached here.