Traditionally, when programmers hear the words Configuration Management
, they react
negatively. It's true that CM can be perceived as slowing programming down, because it
adds some extra steps to the daily process. These steps also take away some of the
"shoot from the hip" mentality that good programmers are known for, and they naturally
rebel against the imposed discipline, seeing it as a restrictive environment. If the
project is small, with only one or two people working on an application, and if the
application is not too involved, CM issues may never be a problem.
On larger, longer projects that require more manpower, these issues become more important. The truth of the matter is, CM can save time in the long run, if a good plan is set up to begin with and followed throughout the development cycle. Often CM allows recovery from mistakes, provides insurance against "stepping on" each other's code, and facilitates requirement verification and traceability to reassure the customer. If you have ever felt the frustration of working all night to get an algorithm to run, only to have it fail the next time you run it because someone changed the code (without your knowledge and without making a backup copy first), you can appreciate that CM will help to prevent that from happening. I'll tell you a story or two sometime...
The whole idea behind CM is that at periodic intervals, the source files are "frozen" so that no further changes to those versions can be made. From this point on, any changes to the code require making a copy of the file (a process known as "checking out" the file), modifying the copy, then saving that file as the new version ("checking in" the file). This provides the traceability and recovery (called "roll-back") capability that can save your bacon. There are automated applications that will do this (and a lot more!) for you, but you can mimic their operation by a do-it-yourself plan that enforces the same discipline on the programming team.
For this project, you should decide on a configuration management method or a tool to use. In this document section of the SDF, identify the software configuration management package you will use for your project, how it will be used, and the baseline version(s) you expect to generate. If you will not be using a tool for CM, you should describe the methodology you will use to implement your CM plan in detail, including how you will configure your code, how you plan to maintain multiple versions, and how you will recover from errors or back out of changes when needed. For the deliverable, just make one notebook section that describes the process in detail. If you are using a tool such as CVS, you might provide some information about how the tool is being used to set up and control, and give some specific command examples. Regardless of CM method, you should show the directory structure of the project, indicating what directories will be used for which modules of code. If graphics objects are being used, include them in the descriptions. Likewise, if a database engine is being used, describe how the database files will be controlled. Elaborate on security mechanisms; how can you keep the team members from being able to erase something by accident?
During the course of the project, you should generate at least an alpha version, a beta version, and the final version.
Since our teams in this class are small, it is probably OK for everyone to be operating in the CM tool (or participating in the plan) by checking out code, and checking it in when they are finished. In the industry, however, one person on the project team will be designated as "Software Configuration Management Officer" or "SCMO" (pronounced "schmoe"). This person will be the one in charge of performing builds for release and testing. The SCMO is a very powerful part of the development team, since s/he has the final say in whether a product is built successfully. There is usually also a Software Configuration Control Board, or SCCB, which is responsible for the review of all changes and additions to the code. The SCMO is frequently the leader of the SCCB.
A number of good CM tools are available. One of the most widely used is the free program called CVS. This program has versions available for all operating systems, and is easy to install, configure, and learn. The CVS tool is available for download from the CVS site. There are also complete directions for use, and "man" pages available, so I won't go into CVS too deeply here. In addition, our own Caskey Dickson often has a CVS lunchtime seminar to explain how we use the system in the Keck lab, and how your projects can be captured and maintained in that environment. All LMU CS students can use the CVS system in the lab for free, Caskey can set up your CVS project area for you in a minimal amount of time when you ask him, and the system will integrate nicely with a number of IDE and development tools.
A follow-on to CVS is called "Subversion", which is similar to the CVS tools, but has a couple of
fixes
which the Subversion authors claim makes Subversion better than CVS. It is an
open source project which you can get from the Tigris
web site for free. All the details are available from that site as well, so I won't belabor the
point here.
Another CM method is the "frozen directory" method (I just made the name up, you can call it whatever you wish.) In this CM plan, code is put into a directory that has a specific naming convention (usually including the date somehow) and is set to "read-only" status. Frequently, the owner of the files is changed to be one person on the team (the SCMO) with the remainder of the group's write privileges removed so the files cannot be changed. Because the method is not an application, increased discipline and vigilance are needed to ensure that everything works correctly and everyone adheres to the plan.
Two other programs, which are built in to the UNIX O/S, are called "SCCS" and "RCS". The Source Code Control System, or SCCS, was initially developed in 1972 by Marc Rochkind at Bell Telephone Laboratories. Though SCCS lacks some of the amenities of RCS (a natural result of its early date of development), it is a generally equivalent system and has a few capabilities that RCS does not. As you might guess from the company where it originated, SCCS traditionally has been part of AT&T-derived UNIX distributions. Though its initial implementation was not done in a UNIX environment, SCCS was quickly reimplemented under UNIX V6 and was distributed as part of the Programmer's Workbench (PWB) from AT&T. RCS, which stands for Revision Control System, was developed by Walter F. Tichy at Purdue University in the early 1980s. Implemented later than SCCS, and with full knowledge of it, RCS is a more user-friendly system, and in most ways a more powerful one.
No matter what method or tool is used, as standalone and integration testing is performed on your code, modules or subcomponents should be configured, that is, submitted to the "protected" area. As subsequent tests and/or integration testing is performed, link the piece to be tested with the configured versions of the software, rather than linking with unconfigured copies. In other words set up a build process that will use the checked-in, latest version of every file in the project except the one you are testing. This way you will know precisely what versions of what modules you are working with. Any bugs that show up in the testing process will most likely be due to the module you are testing, assuming that the checked-in versions have been completed, tested, and integrated. Any errors that are found not to be due to the test module can then be more accurately traced and repaired, since the versions will be controlled.