Configuration Management (CM) can be viewed from many perspectives. In the day-to-day world, we see many examples that inherently have CM in the makeup of their form and function. Take for instance, the example of a modern car. It has thousands of parts that comprise the complete vehicle, and the builders of that car had to manage all those parts coming together at the right time to build the completed vehicle. Not only do the parts of the car have to be identified and tracked during assembly, but specific interrelationships between the parts have to be understood.
In this 4-part series, we will cover six SCM design patterns:
- Design Pattern 1: Paper Forms SCM - determining SCM roles and processes
- Design Pattern 2: Version Control – automation of base SCM functions (Check-in, Check-out, on-line forms, etc.) to support single state lifecycle CIs (documents, baselines, etc.)
- Design Pattern 3: Multiple States – support multiple teams (Developers, QA, Customers) working on different views (States) of an Application. Also provides for Management control of CIs and their groupings as they progress through multiple States. A robust relational database that can manage these activities
- Design Pattern 4: Build and Deployment – ability to support diverse CIs, command line interface (API), interface to a build management tool, scripting environment to direct the activities of a build and deploy. A robust relational database that can manage these activities
- Design Pattern 5: Parallel Development – advanced user interface including file comparison, version tracking, branching, and merging. A robust relational database that can manage these activities. Still lacking in tools to evaluate the impact of merging.
- Design Pattern 6: Content Management – Graphics based web interface, large grain SCM, and web site deployment tools
This important concept of CM is that it manages components, their state and characteristics over time, as well as their relationship to other elements in the entire configuration—in this example the completed car. CM systems keep track of things (tires, windshields, seats) and their interrelationships to other things (the tire must fit inside a wheel well, the windshield must fit into a sheet metal frame, and a seat must align with anchor points on the car floor) , not just the things by themselves.
In the world of Software Configuration Management (SCM) we see analogous concepts to those in the physical world; we have to bring together many software components to form a software product, we need to understand the interrelationships of those components, their state over the course of a software project, and characteristics over time. We must also know their relationship to other elements in the entire configuration (a software product like a Web Browser). SCM systems keep track of software components and their interrelationships to other software components, not just the software components by themselves.
Software execution environments are much more complex today than they were in the past. In the past there would have been a single computer, a simple input/output device, a keyboard, a monitor and/or printer. During this period SCM tools usually existed on the computer where the software executed and approvals were performed with paper forms.
In today’s complex distributed development environment it is very easy to get caught up with the “bells and whistles” of modern SCM tools. With all the selling hype we experience today it’s also very easy to think that “ if I can just select the right tool, then all my SCM problems will go away ”. This is absolutely the wrong thing to do! Two major concepts drive any SCM system, no matter if it is a big system or