Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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

 

  • No labels