The Merchant Stand - A Marketing Technology Place

2 Server Patching Approaches

Server patching is one of those infrastructure tasks that most business owners and infrastructure managers don’t link to the eCommerce portfolio. Operating system patches, virus scanner updates, database patches, etc. are all system level software not directly related to the code line of the eCommerce team. Infrastructure managers can certainly create a patching strategy independent of the eCommerce development process, but I like two methods that keep the current version of eCommerce code in the forefront to help minimize risk and make the patching process more efficient.

1. Follow code line promotions

The premise behind this approach is to install and promote server patches in same sequence of non-production environments as the code line increments. So for example a shop might have an environment sequence for code something like this:

Development ⇒ QA ⇒ Beta ⇒ Production

Let say there is a code release version 2.2 that is currently in development. Then as version 2.2 is deployed in sequence to each environment the infrastructure manager would additionally apply all new patches.

The advantage to this approach is that as the code line is tested in each environment the patches are part of that testing. This prevents the team from having a duplicate testing event just for patch validation and should provide a more thorough set of testing before production deployment. Testing patches for potential system incompatibility is always the biggest risk to production deployments. So this approach tries to mitigate the risk by having it tested by various groups in different environments.

A disadvantage to this approach is that the need for server patching may arise independent of the release schedule. Emergency vulnerability patches may arise due to a hacker exploit or some other industry event.

2. Snapshot and test

The idea of this approach is to make a copy of the environment that you will patch and then install the patches to the copied environment. The test team will then validate that there are no code incompatibilities by testing against the new environment. Once approved, the infrastructure manager can promote the patched environment to production or patch the original production environment.

The advantage to this approach is that it can run at intervals independent of code releases. That could be useful if there is an emergency vulnerability patch and the next code release isn’t scheduled for production deployment for another four weeks.

The disadvantage to this approach is that it requires more administrative overhead and management. Depending on how it’s executed you could duplicate tasks. Additionally it creates a separate testing event for the validation team that is independent of the normal test validation associated with code installs.

In practice, it may be best to use both approaches. Following code line promotions is a risk mitigation approach that doesn’t duplicate testing efforts and would work for a routine patch update schedule. The snapshot and test approach works for off-cycle patches that have a more urgent requirement for deployment.