Software Configuration Management

Overview

This document is intended to explore some best practices for software configuration management.

Basics

• All development groups or sub-groups need a versioning strategy

• The versioning strategy must include non-production environments

• Entry to any shared environment requires a strategy for automated build/deploy, version labeling and rollback

Versioning Strategy

It is widely acknowledged that versioning artifacts (be it source code, documents or otherwise), is a good practice. This is easily accomplished through a variety of means. However, environmental complexities can make versioning unwieldy. Some examples of environmental complexities include:

• Multiple artifact owners/contributors

• Multiple versions supported at a given time (through multiple production or non-production environments)

• Dependencies, integration

Among application developers, there seem to be four varieties of versioning strategies in use:

• Concurrent Versioning Systems

• Versioning Systems (not concurrent)

• DIY (folders, spreadsheets, etc.)

• Nothing

Any of these may suffice depending on the overall complexity of the problems being solved. This document intends to make a case for moving from a lighter strategy to a more robust strategy as problem complexity increases. Many organizations face all of the complexities mentioned above, but in many cases application development is not prepared to manage them.

Analysis

There are some key questions an application developer may want to ask when solving a problem having to do with artifact contributions:

• Does this problem require multiple people to contribute to an artifact?

• Does this problem require multiple people to contribute to an artifact at one time?

• Does this problem require multiple people to contribute to an artifact at one time who do not reside in the same location?

• Etc.

Without furthering that line of questioning, it may become apparent that the logistics behind a multi-collaborator environment would be more easily solved with the help of a tool.

A similar line of questioning can apply to the complexity of versions:

• Does this problem require supporting multiple versions of the solution?

• Does this problem require supporting multiple versions of the solution at one time?

• Does this problem require supporting multiple versions of the solution at one time in a single environment, multiple environments, production, non-production…

• Etc.

Tenets

Given a brief analysis of common problems/questions and techniques listed above, this section is intended to submit, for discussion, a list of tenets for application development:

1. All project groups or sub-groups need a versioning strategy

2. The versioning strategy must include non-production environments

3. Entry to any shared environment requires a strategy for automated build/deploy, version labeling and rollback

4. Configuration should be separate from code

5. Code is not compiled in production, but rather it is migrated from an environment where it has been validated (see tenet 4)

Questions to Consider

• Can I progress through the environment stack from bottom (dev) to top (production)?

• Can I progress through the environment stack from top to bottom?

• Can I support multiple versions across environments (production or otherwise) at one time?

• Can I rebuild/restore an environment to any version, from any version?

• Can I have backwards compatibility?

• Can I do all of these things in a repeatable way?

For all of the questions above it may not be necessary (or even a good idea in some cases) to do the things listed in the question. However, the real issue is whether you are nimble enough to do it when the problem you are solving calls for it.