Current Address:
berczuk@acm.orgConfiguration management is part of an efficient development process. As with other aspects of software development, configuration management happens in the presence of social and organizational constraints. The various goals of configuration management (stability, developer independence and interaction, etc.) sometimes conflict with each other. This paper presents three configuration management patterns and shows how the forces between them balance out. It also relates them to organizational patterns.
Software configuration management (SCM) is an important aspect of development process. A good SCM process makes it possible for teams of developers to work together on a project effectively. While there are various tools that can make the process simpler, there are certain patterns for software configuration management that exist unsuccessful development organizations.
A successful configuration management process allows:
Attaining all of these goals involves compromises (many people working of one body of code makes maintaining consistency difficult, for example). This paper presents 3 patterns that illustrate how the problems presented by configuration management problems can conflict with each other, and how the various forces can be balanced. We also show how SCM interacts with some of the organizational process patterns described by Coplien [5] and the Development Episodes Patterns of Cunningham[6] .
The goals of this paper are to:
The patterns are illustrated with an example which has the following participants:
This section summarizes the intents of the patterns.
A developer should have a way to checkpoint changes without making these changes available to the development team at large. We want to implement Code Ownership(17) [5] but subsystems never work entirely in isolation.
Periodic integration of a developer's work with that of other members of the development team is important for ensuring stability. Checkpointing only after completing major changes can make it difficult to back off of one phase of a change. Using the revision control area for this can lead to changes being "published" before they are ready for integration. Also, publishing intermediate changes can lead to a deceptive number of revisions listed in the SCM system. It is necessary to be able to save intermediate steps in a change in case a coding step results in an error. This is particularly important when:
therefore:
Developers should be provided with a mechanism for check pointing changes at a granularity that they are comfortable with. This can be provided for by a local revision control area, Only stable code sets are checked into the Project Repository
Add a Private Repository to the Developerís Workspace so that a developer can save intermediate versions before checking them in to the Repository. The Private Repository can use the same mechanisms as the Project Repository (ie, RCS) or can simply be a means of maintaining copies of intermediate files.
It is important to make sure that developers using Private Versioning remember to migrate changes to the shared version control system at reasonable intervals.
The revision control mechanism could also provide a means for restricting access to checked-in versions that are not yet ready for use by others, and could also provide a mechanism for filtering log messages to eliminate trivial changes.
The project repository using CVS for version control. Add to the Developer workspace a shadow directory in which there is an RCS directory for the developerís use only. The developer copies files to the ìmainî development area before checking them into the project repository.
Some organizations have infrequent integrations which reflect large changes. This can make it difficult for the integration release to work as expected, complicate the process of Work Integration[6] and make Named Stable Bases. [5] difficult to achieve when modules do not work together. Because we often develop with one Owner Per Deliverable[1] there will be occasional mismatches between units.
For iterative development to work well, it is necessary to make sure that components work together. Subsystems get developed at different rates. Developers work with Independent Development. We need to find a way to make it possible to integrate without surprises.
therefore:
Provide a mechanism to allow developers to build all the current software periodically. Developers should be discouraged from maintaining long intervals between "check-ins." Developers should also be able to build against any of the Named Stable Bases, or the newest checked in software, at will.
Assign the task of building the entire software system periodically. Named Stable Bases suggests intervals no more frequent that a week. This periodic build should be checked for interface compatibility (does it compile?) and testing (Does it still work?) Encourage developers to build from files that are likely to be in the release (perhaps the newest code in the revision control systemís trunk) to anticpate, and allow time to correct for, incompatibilities. The goal is to avoid a ìBig-Bangî integration and allow the Developmental Build[6] to proceed smoothly.
This can be combined with Independent Development to ensure that the changes integrate with a copy of the current development system. There are issues relating to the size of the software system (some systems take quite a while to build, making frequent integrations difficult). Balance this with Private Versions to allow the developer some leeway on deciding when to integrate their new code into their environment, but do not put it off for too long.
The Developerís Workspace could be updated (at the developerís request) to a named stable base from the Project Repository approximately weekly. The developer will also retrieve the current files from the repository to anticipate how the current changes in the Workspace will work with files that may later be in the baseline.
It has been decided to implement Named Stable Bases (31) [5] However, we must balance the need to keep up to date by Incremental Integration, with the desire of developers to maintain a stable environment for feature development/bug fixing, enabling a Programming Episode [6] to proceed smoothly.
How can we balance the need for developers to use current revisions, based on periodic baselines, with the desire to avoid undue grief by having development dependencies change from underneath them?
It is important for developers to work with current versions of software subsystems to keep up with the latest enhancements, avoid running into already fixed bugs fixed elsewhere, and to avoid getting out of synch with interface changes. A developer who keeps changes un-released (or not checked in to the version control system) can disruptother team members. Named Stable Bases recommends integrations at an interval of no more than once a week. Introducing new software into an environment while debugging may cause grief by introducing new behavior, and providing distractions because of the time spent resolving integration issues ó in some cases, code may no longer compile due to interface changes.
Some organizations, to facilitate Incremental Integration, will have a shared baseline of code, libraries, etc. Unfortunately changing a code base, even in a different subsystem, can cause problems when there are interface changes, for example. You want to avoid hearing stories about developers leaving a problem at night to view it in the morning with a clear head, only to find that one's test environment does not compile.
therefore:
Provide a mechanism where developers can maintain independent development environments, This allows them to avoid having an integration step interrupt work in progress. The environment should represent a snapshot of all the software being developed in a system, not just the code the developer is modifying. Try to ensure that the private development area is not used as a means of avoiding integration issues.
This pattern conflicts somewhat with Incremental Integration when a developer delays retrieving the current release for too long, so make sure that developers are encouraged to use integrate their code frequently, perhaps by providing a mechanism for easily backing of a difficult change.
A consequence of this pattern is that, depending on how this is implemented, the disk space requirements of a project may grow quickly as N developers will have their own copies of the source code. But often the costs of personnel greatly exceed the cost of an extra disk. A modification to this approach is that stable, and distantly related subsystems can be used by reference, but one should be made aware of when changes are imminent. In this case the CM system should provide access to prior Named Stable Bases as well.
A variation on this pattern is to allow developers simply to defer advancing to a new Named Stable Base until the current problem is solved.
A developer is working on a problem The Developer Workspace is self contained with all of the files needed to build the system. The Developer workspace gets updated only at the developerís request, after the problem is solved in the context of the current Names Stable Base.
Software configuration management occurs at all development organizations, with varying degrees of success, and these patterns were improved by input from people with different experiences. Javier Barreiro and Neil Harrison for provided me with other perspectives on configuration management. Royce Buehler and Doug Alan worked with me on many of the issues for the configuration management system at the MIT Center for Space Research, on which some of these patterns are based. David Ting first brought SCM issues (particularly those involving remote teams) to my attention while I was at the Kodak Boston Technology Center. My PLoP shepherds, Russ Corfman and DeLoy Bitner and the members of my PLoP 96 working group made many suggestions which improved this paper.
The development of the SCM system at MIT, which inspired these patterns, was supported in part by NASA/GSFC contract NAS5-30612.
1. Cockburn, A., The Interaction of Social Issues and Software Architecture. Communications of the ACM, 1996. 39(10/ October 1996): p. 40-46.
2. Berczuk, S.P., Organizational Multiplexing: Patterns for Processing Satellite Telemetry with Distributed Teams, in Pattern Languages of Program Design, J. Vlissides, J. Coplien, and N. Kerth, Editors. 1996, Addison-Wesley: Reading, MA.
3. Berczuk, S.P., A Pattern for Separating Assembly and Processing, in Pattern Languages of Program Design, J. Coplien and D. Schmidt, Editors. 1995, Addison-Wesley: Reading, MA.
4. Humphrey, W., Managing the Software Process. 1990, Reading, MA: Addison-Wesley.
5. Coplien, J.O., A Generative Development Process Pattern Language, in Pattern Languages of Program Design. 1995, Addison-Wesley: Reading, MA.
6. Cunningham, W., Episodes: A Pattern Language of Competitive
Development, in Pattern Languages of Program Design 2.
1996, Addison-Wesley: Reading, MA.