The single most important action that can ensure
the success of a software patch is to first test the changes in a
nonproduction environment. Every environment is unique, and patch
testing can uncover potential problems unique to the environment in
which the patches will be installed. If you test thoroughly, you can
reduce the chance of encountering problems with new patches.
The level of testing you perform depends in part
on the patch management strategy you choose. For example, because
proactive patching involves installing patches before a problem occurs,
it allows more time than reactive patching to complete a sufficient
level of patch testing.
HP subjects all General Release (GR) and Special Release (SR) patches to extensive testing.
See Chapter 3: “HP-UX Patch Overview” for more information about GR and SR patches. However, it is impossible to test all permutations of all
patches on all hardware configurations. Therefore, prior to deploying
the patches on production systems, you should test the set of patches
you intend to install in a test environment that closely simulates
the production configuration. Even if you are deploying a standard
HP-UX patch bundle, you should still perform testing. Deploying
any patch without first testing it in an environment increases a system's
exposure to risk.
The following is an outline of a basic patch test
scenario:
The patches to be installed are identified and acquired.
The acquired patches are installed on a test system
and tested to a standard that your organization considers acceptable.
Many organizations break this step into multiple levels of testing
to accomplish distinct goals. If testing results in unsatisfactory
results, you must perform an investigation to identify the root cause
of the problem before proceeding.
The tested patches are installed on production systems.
The success of your testing approach relies heavily
on how closely the configuration of the test environment matches the
configuration of the production systems on which the tested patches
will be installed. Within hardware limits, it is a best practice to
duplicate the production environment as closely as possible.
Ideally, you have a test system that is identical
to the production system on which patches are to be installed, and
you have sufficient time available to test all patches prior to deploying
them. This situation allows you to perform very effective testing
to verify that the patches to be installed will not result in unexpected
or undesirable system behavior.
Many customers have a two- or three-tiered approach
to testing. Patches are initially installed on a system that is often
referred to as the development system. These types of systems are
used for local development. In a three-tiered system, after certain
organization-specific rules have been met, the patches are installed
on another system that is often referred to as the test system. The
patches must then meet another set of organization-specific rules.
For example, many customers require that the patches be installed
on the test system for some specified period of time with no problems.
The amount of time varies widely and can be as short as a week. However,
for many customers, one to three months is considered a reasonable
time frame for testing. Once these rules have been satisfied, the
patches are installed on one or more production systems. Customers
who initially install the patches on only a subset of their production
systems typically monitor these systems for several weeks prior to
installing the patches on the remaining production systems. For reactive
patching, the longer testing time frames are usually not reasonable
and a stripped-down approach to testing is usually required.
Printable version
