Release-Time Product Configuration Management Pattern

This post is a continuation of a series related to product configuration management (PCM) patterns. This post discusses the implementation, features and drawbacks of the release-time PCM pattern. The primary distinguishing factor between the release-time and the code-time or build-time PCM patterns is that the release-time PCM pattern does not require new full builds to run in order to produce new product configurations.

A typical mechanism used to implement a release-time PCM pattern is to store product configuration information into a separate file that the product can query at run-time. In order for this to work, the application must contain code for supporting any functionality that can be activated via the configuration file. This introduces some security risk since it might be possible for an end-user to alter or replace the configuration file, thereby gaining access to functionality to which they are not entitled. Encrypting the configuration file will make it more difficult for end-users to modify the file, though it will not prevent them from replacing it with one obtained from a different SKU. Further techniques can be employed to tackle such hacking approaches, though if security is more important than PCM agility, then code-time or build-time PCM patterns may be more appropriate.

One of the biggest benefits of the release-time PCM pattern is how quickly changes to product configurations can be made. Let’s assume for now that the configuration file is simply a list of properties (property=value) in a text format. Each property corresponds to some configurable item, like a feature or product name, and the property values can be text or numeric. Here is a small example configuration file:

Videos=1
Tutorials=1
Product Name=Make-Me-Money Deluxe Edition
Product Version=10.0
Splash Screen=Deluxe
Help Files=Deluxe
Advanced Financial Tools=1

In the simplest case, all that is needed to release a new product version is to start with a pre-built product installer and modify the configuration file. This simple case assumes the following are true:

  • The configuration file is exposed as a separate file in the product installer (as opposed to stored in a compressed archive)
  • The configuration file is in a format that can be easily edited (like a text format)
  • The set of available properties in the configuration file provide sufficient flexibility and options to define the desired product configuration.
  • The product installer contains everything necessary to support any combination of settings in the configuration file

The first two assumptions are relatively straightforward and easy to meet, but the last two can be a bit more involved. Both of these require a substantial amount of preparation work in the code base.

Conditional Run-Time Checks

In the build-time PCM pattern, conditional preprocessor blocks were used to surround code associated with certain configurable features. To support the release-time PCM pattern, these conditional preprocessor blocks will need to be transformed into run-time conditional blocks. Instead of the compiler deciding whether to include the code at build-time based on how build variable are set, the application will decide whether to execute the code at run-time based on settings in the configuration file. The following example shows the changes made to the example from the build-time PCM pattern post:

// Add menu items to help menu
AddHelpMenuItem("Make-Me-Money Help", MainHelpRoutine);
AddHelpMenuItem("Register", RegistrationRoutine);
if (ConfigurationBool("Videos") == true)
{
    AddHelpMenuItem("Financial Videos", ShowVideosRoutine);
}
if (ConfigurationBool("Tutorials") == true)
{
    AddHelpMenuItem("Tutorials", ShowTutorialsRoutine);
}
AddHelpMenuItem("About Make-Me-Money", AboutRoutine);

The changes above rely upon a new function named ConfigurationBool. This function will handle the process of querying the configuration file for a Boolean property of the given name, and will return true or false depending on the setting of that property. Other functions would also need to be provided for different types of property values such as string, integers, etc.

Configuration-Specific Resources

Conditional code segments only cover a portion of what can be controlled via product configuration. In many cases, different resource files may be necessary to support different configurations. This can include things like splash screens, help files, and tutorials. These types of files lack the logic capabilities necessary to query configuration settings, so they can’t configure themselves like code can. Instead, all possible variations of these files must be available in the product installer so that the appropriate one can be selected based on the current configuration. This selection could be performed at install-time so that only one instance of each resource is installed, or it could be performed at run-time with the application choosing from among multiple installed resources. In either case, preparation work will be needed to ensure that all resource file variations are produced in a single build and included in the product installer.

In some cases, it may become an unwieldy task to include all possible variations of a resource, as the number of such variations could be enormous. This is especially true of resources that vary according to multiple configuration variables. For example, splash screens often contain the following types of content that can vary as described:

Content Type Variations
Background Artwork Varies according to the channel through which the product is sold (Retail, e-Tail, OEM, VLP, etc.)
Product Branding Varies according to the major SKU for which the configuration is associated (Basic, Standard, Deluxe)
Localized Text Varies per supported language (English, French, German, etc.)

Given the above, and assuming 10 different backgrounds, 5 product brands and 20 supported languages, a total of 1000 variations of the splash screen would need to be produced. If each one of those splash screen resource files was 1MB in size, then this would add 1GB to the size of the installer. This is obviously an undesirable consequence which more than offsets the benefits of release-time configuration capabilities. However, there are methods which can be employed to reduce this kind of problem.

The problem described with the splash screen arose primarily due to the interaction of multiple configuration variables on a single resource. Each configuration variable increases the dimensionality of the resource, with the universe of possible variations being defined by the product of all dimensional magnitudes (10 backgrounds x 5 brands x 20 languages). The best way to avoid this problem is to organize configuration variables such that no more than one variable applies to a given resource.

For the splash screen example, one way to organize with one configuration variable per resource is to divide the splash screen into three separate resources (background artwork, product branding, and localized text). If each of these resources were stored separately, a complete splash screen could be reassembled at application run-time by overlaying the product branding and localized text onto the background artwork. Using this approach, the product installer would need to include 10 different backgrounds at 1MB each, 5 product brand graphics at 100KB each, and 20 sets of localized text at 2KB each, for a total of 10.54MB of data. That’s a size savings of two orders of magnitude. While it is still an order of magnitude larger than including a single splash screen, it is a manageable size increase that is more than offset by the benefit of being able to produce any configuration from the same base product installer.

Preparation Effort

Now, let’s take a look at the work involved in managing product configurations using the release-time PCM pattern. The preparation effort will be increased over that for the code-time and build-time PCM patterns. It will involve the insertion of conditional run-time checks of the configuration file to control the execution of certain functionality. The conditional run-time checks in turn will rely upon the development of functionality for querying the configuration file. Additionally, functionality will need to be developed to assemble the splash screens dynamically at run-time from component resources. To help make the production of help files configurations more manageable, topics for configurable features will be placed in separate help files, and a master help system engine developed to dynamically aggregate the help file topics at application run-time based on configuration settings.

It is possible to substantially optimize the testing process for products that use the release-time PCM pattern. As with the build-time PCM pattern, QA can be assured that the same code base is being used for all configurations. The release-time PCM pattern further assures QA that the same program binaries are being used for all configurations. This allows QA to structure test plans to separately handle common functionality and configuration-specific functionality. The common functionality need only be tested once per build, while the configuration-specific functionality would be tested per-configuration, per-build. However, further optimizations can be made based on the ability for QA to easily edit the configuration file.

Since QA can edit the configuration file, test plans can be structured to test each option independently to verify that the option functions as expected for all possible settings. For those options that have an unlimited number of settings, such as Product Name, tests could exercise restrictions on name length, invalid characters, localized text, etc. Once all of the available configuration options have been tested independently, then configuration-specific testing can be reduced to simply verifying that the configuration is set up the way that it is supposed to be.

Configuration Set Up Effort

Once the preparation effort is complete, and assuming the available configuration options satisfy the present configuration needs, the configuration set up effort will be extremely small. It simply involves the editing of the configuration file for a pre-built product installer.

Test/Fix Effort

Since all of the testing to make sure that the configuration options work correctly is now part of the common functionality testing, the configuration-specific testing is simply a check of the configuration file to ensure that it matches the configuration specification. If it doesn’t then a bug is entered and submitted to the product manager to correct. The fix can be made without a need for a build and resubmitted immediately to QA for verification.

Effort Summary

Following is a summary of the effort involved in handling multiple product configurations using the release-time PCM pattern:

Worker Time Machine Time Work Description
40 hours Insert conditional run-time checks
80 hours Develop functionality to query configuration file
80 hours Develop functionality to assemble splash screens
160 hours Divide configurable feature topics into separate help files
80 hours Test preparation for configuration options
440 hours 0 hours Sub-total – preparation effort
30 minutes Edit configuration file
30 minutes 0 hours Sub-total – configuration set up effort
15 minutes Testing time for 10 QA Engineers for each sweep
15 minutes Time for 1 Product Manager to fix configuration setting
30 minutes 0 hours Sub-total – Test/fix cycle
441.5 hours 0 hours Total effort assuming 2 test/fix cycles

Nearly all of the effort involved with managing configurations in the release-time PCM pattern is in the preparation phase. The amount of preparation effort is independent of the number of product configurations, and is thus a one time cost. While it is a large cost, once the preparation is finished, there is very little effort needed to handle the set up, testing and fixing of configurations. This positions the release-time PCM pattern as an ideal approach when large numbers of product configurations must be supported. Release-time PCM is best suited for controlling features and options that require only low to medium levels of security protection. High-security needs are better filled by code-time or build-time PCM patterns. The release-time PCM pattern also significantly reduces the burden on build system resources, and it can achieve extremely rapid turn-around for both new and modified configurations.

About Daniel Brannon

Daniel Brannon founded OSoSLO in 2009 to provide software tools and services for business and technology professionals.
This entry was posted in Product Configuration Management. Bookmark the permalink.

Leave a Reply