Defining Software Configuration Management

Let's define SCM as it is used in this book. I like this definition of configuration management that Steve McConnell gives in his 1993 book, Code Complete, from Microsoft Press:

Configuration management is the practice of handling changes systematically so that a system can maintain its integrity over time. Another name for it is change control. It includes techniques for evaluating proposed changes, tracking changes, and keeping copies of the system as it existed at various points in time.

A more detailed description might be from Stephen A. MacKay. He quotes several sources, but they all seem to be saying the same thing:

The most widely used definition of software configuration management (SCM) comes from the standards community [IEEE87, IEEE90a, IEEE90b, Buck93]. Configuration management (CM) is a discipline that oversees the entire life cycle of a software product or family of related products. Specifically, CM requires identification of the components to be controlled (configuration items) and the structure of the product, control over changes to the items (including documentation), accurate and complete record keeping, and a mechanism to audit or verify any actions. This definition is not complete. Dart [Dart92] suggests that the definition should be broadened to include manufacturing issues (optimally managing the construction of the product), process management (ensuring adherence to the defined processes), and team work (supporting and controlling the efforts of multiple developers). Tichy [Tich88] provides a definition that is popular in the academic and research communities: Software configuration management is a discipline whose goal is to control changes to large software system families, through the functions of component identification, change tracking, version selection and baselining, software manufacture, and managing simultaneous updates (teamwork).

In short, at Microsoft, SCM is broken into three groups: source control, build, and deployment or release. There could arguably be a fourth group, sustained engineering hotfixes and service packs but this separate distinction seems to show up only on the big teams such as Windows. The jobs at Microsoft that have the responsibilities described previously are builder, build management, or release program manager.

The really abbreviated term for SCM at Microsoft is builds. This is probably because when code is taken from developers and turned into a product that you can deliver to a customer, it is usually the build team that owns all the steps involved or helps manage the process.

Having a good build process seems to be a lost art even in some groups at Microsoft. For example, when I recently spoke with one development team, I heard them talk about trying a distributed build system over a group of build machines (also known as build farms). This idea was tried several years ago and tried a few times since the original but has proven to be unsuccessful for various reasons that are covered in Chapter 5, "Build Tools and Technologies." Maybe there have been recent improvements in tools, or the product has been broken into smaller packages of code (componentized) that will make this distributed build process more likely to succeed today than it did years ago. If so, this might justify revisiting the idea even though it was abandoned the last time someone looked at it. But if no changes have been made that would support moving to a distributed build process, trying to pursue this Holy Grail would be a waste of everyone's clock cycles.

It is impossible to talk about software builds without also addressing some of the surrounding software development areas around this process, such as source tree configuration and the deployment of a product. Therefore, I want to give the full story of setting up your development source trees, building your code, deploying your product, and supporting your customers with fixes by using examples of how we do it at Microsoft.