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. There are fine details about the status of requirements and defects in multiple locations, depending on the kind of requirement, and how far it made it in the development process.
- START Replacement requirements were formal requirements made by Kesha Petal in 2013, and stored in sharepoint. However, subsequent expansions were made to the requirements and and defects are documented in HPALM. There was very little scope left for Telephone Services defects, and that particular scope is documented at Completing Telephone Services START Replacement forms, June 2014. I still have apply order saved as part of the file application_order_as_applied_test_vs_prod_2014-04-23.txt
- CMDB requirements were formally project managed by Tim Nichols. There were approximately fourteen phases planned, and about seven phases were completed before work was stopped on the project. The individual requirements and defects are documented in HPALM. There aren't all that many of these, and they should be QA'd as if they had not previously been unless otherwise marked.
- April 2014 release. There were about 140 update sets involved with the April 2014 release, although the exact number is probably smaller after two requirements were judged as unwanted by the stakeholders after UAT. The fine details for that release, including application order are available at requirements advanced to PROD for Start replacement#June??,2014(May21,2014tentatively,thisisthenever-launched2014-04-24releasewithR780,R812,R1147removed)
- Notifications work. There was a flurry of work shortly after the February 2014 release regarding notifications overhauls. That work was tested throughout Spring 2014, but all the testing results were lost when we cloned over TEST as part of the April 2014 release that was later cancelled. I still have apply order saved