CM Generations and a Vision for the Future

By my reckoning, the past 15 to 20 years of CM technology and process advances have produced, what I would call, the second generation of CM and many strides have been made by various parties toward the third generation. Over the remainder of the decade, we'll see some CM vendors bring forth their third generation solutions - indeed one or two already have. The fourth generation lies beyond that.

The CM industry is always in need of some vision, set forth by the innovators, the practitioners and the user-community. As with most technology advances, CM will only reach the bar we set for it. How do you recognize next generation tools, that is, apart from the marketing hype? And what will the CM landscape look like over the next 2 generations?

If you're building a Missile Defense System, a new generation of Aircraft, or a tamper-proof Financial System, you'll want to position yourself to best take advantage of new technology. Lets take a brief look at the past and present to prepare us to look into the future.

First Generation CM

The first generation of Configuration Management tools dates back to the late 1960s and the 1970s, with SCCS (Unix), then RCS and a number of mainframe capabilities such as CMS (VMS). Through the 1970s, CM began to take a formal foothold. Most solutions were still in-house solutions, but usually based on a basic version control program such as SCCS.

The initial set of CM tools provided the most basic Version Control and Build facilities. These were typically a collection of tools, sometimes formally grouped, sometimes informally grouped. First Generation CM tools are identified by the following properties.

• Configuration Item/Unit Identification, including Revision identification schemes
• Check-out and Check-in of files, with exclusive check-out support
• Basic Branching and Branch Identification capability
• The ability to retrieve a file without reserving it for check-out
• The ability to compare revisions of a file and perform basic merge operations
• The ability to define and capture forever a baseline definition
• Basic Integration with basic Build/Make tools
• Some level of scripting support, perhaps through the OS environment

First generation tools were not user-friendly. Developers were used to the command-line and a few extra commands to safeguard their source code was not a big deal, as long as the system was reliable. The CM manager's job was anything but defined. The one clear goal was to be able to produce nightly/weekly builds and to be able to reproduce them as necessary.

Second Generation CM

During the 1980s and 1990s, ideas within the CM community pushed capabilities through a second generation (2G) with some key advances. One of the key advances, still being absorbed by the some CM vendors and consultants, is the concept of managing changes rather than files. Most other advances dealt with optimization of the basic CM capabilities. 2G CM advances include:

• Change packaging and basic change management
• Revisioning of directory structure
• Support for semi-automatic Baseline definition
• Sharing of Revisions across Development Streams/Releases/Branches
• Support for Makefiles and build scripting
• Source Code Bulk-Loading Capability, usually through scripting
• Exclusive and Parallel Checkout Support
• Branch and Label Management or equivalent.
• Distributed Build Capability, especially since computers were significantly slower
• Integration with SCC API Compliant IDEs, late in the '90s
• Basic workspace support

In the second generation, CM advances were not limited to CM tool capabilities. Perhaps even more so, focus was placed on other CM issues: Process, Useability, Reliability and Administration and Performance issues. Tool administration saw two key advances

• Concurrent Unix and Windows platform support
• Scalability of the solution to support hundreds of users

From a reliability perspective,