Serviceability

Heath Stewart

It’s always important to test your product before it ships. Servicing it later can prove very costly and very difficult. It’s no different with your installation packages. You need to test not only basic install and uninstall operations, but also test your servicing plan. Problems are inevitable in practically any application, and you may even need to add in additional features. So test that you can before your product ships.

Before testing your product deployment, you need to define and document what you will conceivably support. Many of the following options supported by Windows Installer are also supported by other deployment technologies.

• Small update patches
• Often used for hotfixes
• Great for updates to a few files.
• Does not create a new baseline
• Requires target product to be installed
• Minor upgrade patches
• Often .used for service packs
• Great for updating a larger set of files
• Creates a new baseline
• Requires target product to be installed
• Small update packages
• Does not create a new baseline
• Does not require the target product to be installed
• Requires a bootstrapper to reinstall and recache the package  if a package with the same ProductCode is already installed
• Minor upgrade packages
• Creates a new baseline
• Does not require the target product to be installed
• Requires a boostrapper to reinstall and recache the package if a package with the same ProductCode is already installed
• Major upgrade packages
• Often referred to as “rip and replace” packages
• Creates a new baseline
• Does not require the target product to be installed
• Does not require a bootstrapper to reinstall
• Side by side installations
• Creates a new baseline
• Supports multiple versions of products installed simultaneously
• Require different ProductCodes
• Works best with few or no shared components

When you have documented how you will service your product, be sure to test all combinations. For example, if you will use small update patches for hotfixes but minor upgrade patches for service packs, test installing patches on both the initial release (RTM) and a service pack. You should also test more than one service pack to make sure all update scenarios are covered.

Besides testing different scenarios, also test your different resources types. Whether you have versioned files (ex: EXE, DLL), unversioned files (ex: TXT, XML), registry values, services, COM servers, any custom resource types, or a mixture of different resources types, test them all. Different types of resources upgrade differently or are adversely affected by multiple products having install the same set of resources (shared components).

Once you have documented and tested a particular servicing plan, try to stick to it. Changing tactics later may not work and can cause issues.

Heath Stewart Senior Software Engineer, Azure SDK

Follow