In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
What an accomplishment: thirty-three miners rescued in Chile after sixty-nine days of being trapped. If the technology was there to drill the escape route, and to design the capsule to bring them up, but the rest of the team wasn't integrated - success would have been difficult at best. There were psychiatrists and psychologists, medical experts and nutritionists, project managers, rescue workers, and overall co-ordination, in addition to the engineers. The whole team worked together for success.
In software, it's much the same. You can have an engineering team with great version control and even CM tools produce a great application. But if the verification team, the documentation team, the marketing team and the project management team aren't on board, the great application may never see the light of day. The whole team has to be involved. The application has a lifecycle, from conception to retirement, the application lifecycle, and it has to be managed.
Perhaps when there was less market pressure, or fewer applications and products with far fewer computers, it was fine to focus on software design and implementation. In those days of old, managing the new flexibility and capabilities afforded by software was the big challenge. But we've come a long way since then.
The First Generation
In the early days of software, the late '60s and early '70s, a new capability known as Version Control (VC), or Source Code Control (SCC) evolved on a number of different fronts including IBM (for their mainframe code), AT&T (for their Unix code and telecomm product code), and DEC (for their own PDP and VMS software).
I believe the IBM product was called update (or some variant thereof). It captured updates to be applied to a file, and so maintained a capability for retrieving files with any number of updates applied. Digital's product was known as CMS, for code management system. And AT&T's Unix tool Source Code Control System (SCCS). Perhaps some of you have been exposed to all of these. They were the forerunners of the current CM tools. SCCS in particular was very widespread in the Unix world and made its way over to VMS as well.
A number of other VC tools evolved over time: RCS, PVCS, CMVC, etc. They dealt primarily with 4 basic functions:
- Save/retrieve revisions (i.e., versions) of source code
- Creation of baselines
- Checkout/check-in functions
- Branching of source code files
In addition, the Make utility, and other similar capabilities evolved so that the code baseline, once retrieved from the version control database, could be built in a repeatable fashion. Other tools, such as diff and merge/diff3, evolved to support workspace management, including peer reviews of changes in your workspace, and merging parallel changes into your workspace.
This was the first generation of what soon came to be called (software) configuration management tools. The goal was modest and easily accomplished. Version control continued to evolve for many years with schemes to improve retrieval time when there were numerous revisions, capabilities to track checkouts, and the ability to add comments to each revision.