...

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

...

Applying update sets properly in this scheme requires a few things working together:

...

• 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 Fine detail is also available in Trello.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. Fine detail is also available in Trello.
• 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) Fine detail is also available in Trello. 
• 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. Fine detail is also available in Trello.
• 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

...

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 5 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.

...

• 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 were wantedare restored from archive, the process would be to use the notes in HPALM, Trellobox, hereconfluence, and anywhere else documentation ends up. The administrator will also need the update set XML export files, which will probably be stored on box.

...

• 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.