It was 1978 when I first introduced change packages (a.k.a. Updates) as the central feature of an in-house CM system - still in use today supporting a 40 million LOC project. It was 1982 when I introduced the concept of streams to rationalize branching along the product roadmap. Little did I know that a quarter century later, these concepts would just be starting to move to the forefront.
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,