5646 views

Quarterly Patching & Upgrades Program | ServiceNow Patches 

 

Overview

A patch includes a collection of fixes for known problems. Any previously issued hotfixes for the release are also included. Applying the latest patch to your instances provides these benefits:

  • Maintains security
  • Increases availability
  • Improves performance
  • Avoids incidents for issues that have already been fixed

The following sections guide you through applying a patch.

If you do have any issues during or after a patch, please submit an incident to ServiceNow Customer Support.

 

Comparing patches and upgrades

ServiceNow organizes its releases into families. A family is a set of releases that are named after a major city, such as Eureka or Fuji. Within a family, releases are further differentiated by patch and hotfix number. For example, the following releases are both part of the Fuji family:

  • Fuji Patch 1
  • Fuji Patch 2 Hot Fix 1

Upgrading is the act of moving to a release that is in a different family than your current release. For example, if you move from Eureka Patch 8 to Fuji Patch 2, this is an upgrade because Eureka and Fuji are different families. 

Patching is the act of moving to a release that is in the same family as your current release. For example, if you move from Fuji Patch 1 to Fuji Patch 2, this is a patch because both versions are part of the Fuji family.

Note that in both cases, the target release is Fuji Patch 2. It is the difference between the old and new releases that determines whether you are upgrading or patching.

 

Patch release notes

ServiceNow provides release notes for every patch. Read the release notes to view the fixes that are included.

 

Create plan to validate critical functionality

Create a smoke test, or plan to validate critical functionality.

First, identify which services are critical. When evaluating whether or not a service is critical, ask if a top priority incident would occur if the service stopped functioning. If the answer is yes, include that functionality in the validation plan. If the answer is no, consider excluding the functionality.

Then create a set of detailed validation scripts that can be used consistently and methodically to validate the functionality that was identified as critical.

For example, Company A has implemented ITSM (Incident, Problem, Change) and Service Catalog. The company also plans to implement SDLC in the coming months. The following table lists some of the functionality that would be included and excluded from Company A's validation plan.

Included in validation plan
  • Create and update an incident, problem, and change request
  • Create a P1 incident and confirm that the appropriate notifications and SLAs are generated
  • Request an item from the catalog and confirm that the appropriate tasks and workflows are generated
Excluded from validation plan
  • Pick an assignment group on a change request to limit the available assignees appropriately
  • Anything related to SDLC - because SDLC is not live yet in production, it is not a potential blocker for applying the patch

 

Patch and validate sub-production instances


Before patching production instances, patch and validate sub-production instances. Proper preparation and validation on sub-production instances can help ensure a safe and accurate patch on production instances.
Clone production over sub-production
To perform accurate validation, clone production instances over sub-production environments such as development or test. Because production instances are the final destination for any patch, it is important that validation be done on a system that reflects production instances as closely as possible.
If your selected sub-production instance has been recently cloned and is on the same version as production, you might consider skipping the cloning step. Please note that this does come with additional risk because it is possible that the sub-production instance without a clone does not completely mimic the production instance.
Use the System Clone application to clone production instances. The application automates much of the process and enables users with the admin or clone_admin role to clone data from one instance to another. The default options for System Clone are Exclude audit and log data and Exclude large attachment data, which exclude tables in the System Clone > Exclude Tables list and large attachment data from being cloned. Unless the default options would exclude data required to validate critical functionality, we recommend that you use these options when starting the clone. This minimizes the time required to complete the clone.
For more details on the cloning process and options, see System Clone.
Request a patch for sub-production instances
If you want to request a patch outside of the Quarterly Patching Program (QPP), see How to manage entitlements and scheduled upgrades.
To change the scheduled time or contact ServiceNow about patches scheduled automatically through the QPP, see Managing your quarterly patches and communicating with ServiceNow.
Instances are fully available while the patch is being applied. After the patch is complete, the change request is closed. A notification is also emailed to the reporter and watchers of the change request.
Validate patch on sub-production instances
After a patch is applied to sub-production instances, run the validation cases from the validation plan that was prepared for critical functionality. If you find any issues during the validation process, please submit an incident to ServiceNow Customer Support. 

Patch and validate production instance


After validating sub-production instances and resolving any issues, patch and validate your production instances.

As with any change to your production environment, communicate to your users that a patch will be applied.

Request a patch for production instance

If you want to request a patch outside of the Quarterly Patching Program (QPP), see How to manage entitlements and scheduled upgrades.

To change the scheduled time or contact ServiceNow about patches scheduled automatically through the QPP, see Managing your quarterly patches and communicating with ServiceNow.

Ensure that the patch is scheduled for a negotiated and suitable time for all users of the ServiceNow system. For example, consider scheduling the patch for after business hours to minimize user impact.

Instances are fully available while the patch is being applied.

After the patch is complete, the change request is closed. A notification is also emailed to the reporter and watchers of the change request.

Validate patch on production instance

After the patch is complete, run validation scripts for production functionality. If you find any issues during the validation process, please submit an incident to ServiceNow Customer Support.

 

Lessons learned


Optionally, after the patch is installed, conduct a lessons learned meeting to review the patching process. Document possible improvements and ensure that they are incorporated into the next patch cycle.

Article Information

Last Updated:2018-09-27 13:44:35
Published:2015-07-06