The software configuration management patterns, identified by Steve Berczuk and Brad Appleton, offer practical advice for integrating SCM activities with routine software development tasks. When understood by both configuration management engineers and developers, the patterns translate abstract SCM concepts into practical solutions to common problems.

In their book, Software Configuration Management Patterns: Effective Teamwork, Practical Integration, Steve Berczuk and Brad Appleton group the SCM patterns into two categories: workspace-related patterns and codeline-related patterns. Each type of pattern serves a different purpose. The workspace-related patterns focus on the configuration management tasks that a developer would perform while developing software in a team environment. The codeline-related patterns deal with approaches for branching and merging codelines to support parallel software development.

While each SCM pattern is a solution to a problem in a context, a pattern is not intended to be used in isolation. Instead, the SCM patterns are designed to be used in a manner such that one pattern completes another. When used in this manner, the patterns, taken collectively, form a pattern language.

One of the challenges facing developers working on a team software development project is integrating the changes made by several developers. Empirical evidence suggests that the longer developers wait to integrate code changes, the more difficult the effort is to integrate these changes. Often, large integration efforts result in rework when developers, working in isolation, continue coding to an interface that is also changing. When the two groups of developers fail to synchronize their changes frequently, they find that their code continues to diverge as they develop without integrating their changes.

Even if you are not a proponent of continuous integration (as described by Martin Fowler and Matthew Foemmel in http://martinfowler.com/articles/continuousIntegration.html ), hopefully you recognize the benefits of integrating code changes regularly. The greatest strength of the workspace-related patterns is that they describe concrete activities that a development team can follow to integrate small pieces of newly developed, tested code, in a methodical manner. When used together, the workspace-related SCM patterns help a development team establish both a process and a rhythm that encourages frequent integration of code changes.

Below is an overview of many of the work-space related patterns. The overview is followed by a list of steps that members of a development team can follow to implement the workspace-related SCM patterns to facilitate both frequent integration and frequent testing of code changes.

The private workspace pattern is the foundation of the workspace-related patterns. Stated simply, the private workspace pattern isolates the work environment of one developer from the work environments of other developers. Developers who work in an Integrated Development Environment (IDE) are following the private workspace pattern. The IDE allows the developer to make code changes without interference from code changes that are being made my other developers. The private workspace pattern, implemented by the IDE, allows several developers to make code changes to the same code base in a controlled manner. In other words, the private workspace pattern provides each developer with a development environment that is not in constant flux.

Using the Workspace Update Pattern

The private workspace pattern provides each developer with a stable environment to make code changes. Eventually the code changes made by a developer, working in a private workspace, need to be checked in to the version control system. However, before these changes are checked in to the version control system, the developer should check out code changes completed by other developers. By doing so, the developer can test the changes made in the private workspace to ensure that they work correctly with code changes released by other developers.

The process of updating a private workspace with changes made by other developers is the workspace update pattern. Workspace update ensures that changes made by one developer, in isolation, can be integrated with the latest changes completed by other developers.

Developers who have worked with ClearCase Unified Change Management (UCM) may be familiar with the rebase operation. The rebase operation updates a UCM workspace with changes released by other developers. Java developers who have worked with VisualAge for Java may be familiar with the "Replace With Released Contents" menu option. This option updates a developer's VisualAge workspace with changes released by other developers. Both the rebase operation in ClearCase UCM and the "Replace With Released Contents" menu option in VisualAge for Java are instances of the workspace update pattern.

Before checking in changes to the version control system so that they can be used by other developers, the changes need to be tested to ensure that they implement the correct functionality without breaking any existing functionality. To test the code changes, they must first be compiled.

The private system build pattern allows for a developer to build the entire software application using the changes made in the developer's private workspace. Once built, the developer can unit test the code changes. If the unit test is successful, the changes are ready to be checked in to the version control system.

Eventually, the changes made by a developer in a private workspace need to be checked in to the version control system. Rather than checking in several code changes that may not be related, the task level commit pattern specifies that each check-in to the version control system should be limited to the code changes needed to complete one fine grained consistent task. By keeping each check-in to a single task, it is easy to tie a code change to a task.

In an active software development environment, different developers will be checking in changes to the version control system. Although each developer should perform a private system build prior to check in, this is not a substitute for an integration build. A development team should perform frequent integration builds to ensure that code changes made by developers in isolation work together when they are integrated into a codeline.

Software development projects that perform a daily build are implementing the integration build pattern. The daily build acts as the melting pot where all code changes are blended together.

Whenever an integration build is completed, the build needs to be tested to ensure that the software application still functions. A smoke test is not an exhaustive test of the software application. Instead, a smoke test is designed to exercise the most basic functionality of the software application. The purpose of a smoke test is to verify that the integration build has not caused the software application to break in an obvious way.

While a smoke test verifies that a software application has not broken in an obvious way, only a regression test can validate that new code changes do not break existing functionality. A regression test should be performed following every integration build to verify that the build is successful. If a regression test fails, the source of the error can be identified and corrected before the next scheduled build.

Breaking a build should be viewed as a serious problem. When a problem is introduced, it can snowball if it is not identified quickly and corrected promptly. Only a thorough regression test can determine if a bug has been introduced as a result of code integration.

When grouped together into a pattern language, the workspace-related patterns provide an approach for performing SCM activities in the context of daily software development activities. The steps below comprise this approach. Although not required, the steps below assume the use of an IDE to implement the private workspace pattern.

1. Divide your high-level functional task into small-grained development tasks. Each development task should be sized so that it can be coded and unit tested in about a day.
2. Begin your small-grained development task by creating a workspace in your IDE (if a workspace does not exist). Populate the workspace with all the source code files that make up the software application that you need to modify. By creating a workspace in the IDE you are following the private workspace pattern. The private workspace pattern isolates your development environment from outside changes so that you can work productively in an environment that is not in constant flux. By populating the IDE workspace with the desired source code files you are following the repository pattern. The repository pattern ensures that you populate the IDE workspace with the correct versions of the files that make up the software application under development.
3. Make the changes necessary to accomplish the small-grained development task, but do not check in these changes to the version control system.
4. Run unit tests after completing the code changes in your IDE workspace, but before checking in these changes to the version control system. By executing these tests you are following the unit test pattern to ensure that a software application works correctly after you made small-grained code changes.
5. Build the whole software application in your IDE workspace after completing unit tests. You are following the private system build pattern to verify that the whole application still builds after you made small-grained code changes in your IDE workspace.
6. Start the application built from the small-grained changes made in your IDE workspace. Verify that the most basic functionality still works in this build. You are following the smoke test pattern to verify that the software application has not broken in an obvious way before you check in the changes to the version control system.
7. Synchronize your IDE workspace with the version control system to update your workspace with changes made by others while you were completing the small-grained development task. By doing so, you are following the workspace update pattern.
8. Check in the code changes for your small-grained development task to make them available to other members of the development team. You are following the task level commit pattern to ensure that each check-in corresponds to one small-grained task.
9. Each day, the configuration manager initiates a centralized process to build the software application using the latest code changes that were checked in to the version control system. The configuration manager is following the integration build pattern to ensure that the code base for the web application builds reliably.
10. If the integration build completes successfully, the configuration manager initiates tests on the built software application. The configuration manager is following the regression test pattern to ensure that existing functionality in the software application does not break after new functionality is added.
11. Begin your next small-grained development task by repeating the steps above, beginning with step 3.

Parallel software development is now a routine part of most software development efforts. Even if a software development team does not plan to develop two or more software releases simultaneously, the software development team may need to make fixes in one software release while coding new functionality for another release. Supporting bug fixes in one software release, while simultaneously developing new functionality for another release, is probably the most common type of parallel software development.

By its nature parallel software development can add additional complexity to a software development effort. Attempting parallel software development without first deciding on a branching strategy to support it is likely to lead to confusion and potential mistakes.

The greatest benefit of the codeline-related SCM patterns is the practical advice they offer for supporting parallel software development. Even before a branching strategy is established, the codeline-related patterns can be used to focus discussion on the issues surrounding parallel software development. The codeline-related patterns can be used to educate the entire software development team, including the management, on both the correct and incorrect ways to approach parallel software development. By adhering to the simple principles embodied in the codeline-related SCM patterns, a development team can establish a simple, yet effective branching strategy.

The mainline pattern is the foundation of the codeline-related patterns. When all ongoing software development is kept in a single codeline, the software development team is following the mainline pattern. Use of the mainline pattern does not mean that there is no branching. Instead, use of the mainline pattern ensures that all branches eventually merge back to the home codeline, or mainline.

When the mainline is kept active with frequent check-ins so that it reflects the current state of the software development effort, the mainline is an active development line. An active development line may forgo some stability because the codeline policy that governs the mainline encourages frequent integration. For a software development effort that is in the midst of new development, use of the active development line pattern prevents the code created during that effort from becoming stale.

The task branch and release line patterns provide practical advice for common development scenarios that require branching.

The task branch pattern provides a means for one or more developers to work on a potentially disruptive task in an environment that is isolated for other development activities. The task branch pattern can be used when an organization needs to modify an interface that will impact most, if not all, of the development effort. Using a task branch, the disruptive change can be completed and tested before it is integrated with ongoing development.

The release line provides a means for a team to support defect fixes to a software release without introducing functionality under development for an upcoming release. The release line is a branch off the mainline that exists from the time a production fix is needed until the time when the release is either superseded by another, or no longer supported.

When grouped together into a pattern language, the codeline-related patterns provide an approach for creating and using codelines to support parallel software development. The steps below focus on how to separate different software development efforts based on the characteristics of each effort.

1. Unless you are working on an inherently disruptive task, do all your development work for the next release by checking out and checking in files from the trunk (or a main branch) of the version control tool. You are following the mainline pattern by doing all development work for the next release in a home codeline. You are following the active development line pattern by checking in changes for the next release sooner rather than later.
2. When the release under development is approaching the start of system integration testing, branch a separate codeline from the trunk (or main branch) to fix bugs identified during testing. Begin work for the release after the upcoming release in the trunk (or main branch) of the version control tool. By stabilizing the codeline for the upcoming release while allowing active development to continue in the trunk (or main branch), you are following the release-prep code line pattern.
3. After a release is deployed to production, branch a separate codeline from the trunk (or main branch) to make bug fixes and content changes. You are following the release line pattern by isolating production fix and maintenance work from development work for the next release.
4. When starting work on an inherently disruptive task or a future release, branch a separate codeline from the trunk (or main branch). You are following the task branch pattern to make long-term overlapping changes without compromising the consistency and integrity of the codeline used for active development.
5. Develop and follow rules governing check-ins to a codeline. By doing so, you are following the codeline policy pattern to determine how and when to make a change to a codeline. The codeline policy is what defines the difference between the mainline, the task branch, and the release line.

Conclusion

A sharp boundary does not need to exist between software development and software configuration management. When a software development organization implements both the workspace-related and codeline-related SCM patterns, the organization can integrate SCM activities with software development. Integrating SCM with software development enables an organization to develop software in an efficient and methodical manner. 

Berczuk, Stephen P. and Brad Appleton. 2002. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Addison-Wesley.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment