Background

In July 2014, the ITSM team decided to postpone the development work originally scheduled for release April 2014. That work was tracked here:

requirements advanced to PROD for Start replacement#June??,2014(May21,2014tentatively,thisisthenever-launched2014-04-24releasewithR780,R812,R1147removed)

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 archive this work in a way that allows us to faithfully restore it at a later date.

Primitives

Applying update sets properly in this scheme 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 in file application_order_as_applied_test_vs_prod_2014-04-23.txt.
• Any update sets that don't fall into these categories are probably covered by the attached file File update_set_listing_dev_2014-07-22.csv 
• I'm attaching one more file, which is a listing of TEST, as it was prepared for the June release that did not end up happening. This listing might not be very useful, but in case it ever is, I did not want to lose the data. application_order_as_applied_test_vs_prod_2014-07-21.txt

Actually dumping out the XML-ified update sets

This part is quite tedious. I'm not aware of any method for automation.

• Start with the list of 280 update sets, attached. Clean up DEV. 
• That means mark as ignore the things we don't need to keep, like R780.
  

When we complete that, we also need to prepare for the Clone. We prepare for the Clone by making sure nothing is left in-flight. Meaning, nothing 'In progress'. Everything must either be Ignore or Complete, including the work from Fruition for remediation.

At that point, make next revision of the spreadsheet, that contains the last things that were still 'In Progress'. Either they'll be getting ignored, or they'll be getting set to Complete. We need to have Fruition stop building Health Check Remediation things in DEV, if they have not stopped already.

Filter on just Complete update sets, and use the spreadsheet as a guide to what we are keeping.

• Pick each one individually
• Make an export, save with a descriptive name. The default name is ridiculous. Must manually rename.
• repeat until completed
• That will probably take a few hours; want to be methodical and thorough.
• Then double-check through the files, and make sure we have everything.
  

The script for dumping XML update set exports

Dan Franko has an Aptara script that can dump out the contents of the update sets. He's fixing a minor bug and giving it a try.

How to re-apply in the future

In the future when update sets are restored from archive, the process would be to use the notes in HPALM, box, confluence, and anywhere else documentation ends up. The administrator will also need the update set XML export files, which will probably be stored on box.

For each individual update set, the process is to go to

• System Update Sets -> Retrieved Update Sets. Scroll to very bottom of the page, and select Import XML.
• Provide the file. 
• Once an update set is imported into DEV, it will just be a local copy until the update set is applied. 
• Admin will need to Preview, resolve issues with Preview, then Commit.
• Commit order will need to follow the order specified in the documentation relevant to the Requirement being restored. See spreadsheet and supporting documentation about the order the update sets were applied to TEST when they were under development.
• The folder structure is confusing, and is based on the spreadsheet. If you have trouble finding an update set, just use the find command on unix or similar trick to navigate the tree while searching for the file pattern.
• Backeberg had proposed merging the update sets before export, but it was decided not to do that. Merging would have dramatically shrunk the collection of update sets to retain and reapply in the future.

Auditing the update sets

Backeberg walked through the collection of update sets, and cross-referenced those with the zip file from the box share. He found a full collection of update sets, and set the clone over DEV for Aug. 1, 2014.