Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Using Policies to Effectively Integrate Configuration Management into the Development Process

Written by Adam Kolawa

Thursday, 15 June 2006 08:09

A well-defined and implemented configuration management policy is critical for controlling the software development process and improving its predictability. It is fundamental for automated error prevention, provides control over the software development lifecycle, protects your software assets, and prevents mistakes or inconsistencies from undermining your project's success. Most software development organizations have deployed a configuration management and not infrequently, organizations have deployed more than one. However, common to most organizations is the lack of a clearly-defined policy for effective configuration management system usage, and, as a result, usage is ineffective and inconsistent. Software development organizations with effective configuration management policies have reduced risk of defects being introduced into the project code base during implementation, and are protected against the potential loss or corruption of critical source code assets. If developers are haphazardly working on the same code base simultaneously, the ad hoc file sharing eventually leads to problems such as code for new functionality being overwritten, corrected errors mysteriously resurfacing, or multiple developers duplicating one another's efforts- all of which waste precious resources and may compromise project quality. If the team is geographically distributed (e.g., as a result of outsourcing or telecommuting) or multiple source code control systems and policies are in practice, the potential for problems intensifies. If the source code is stored on developer desktops rather than in a central (and frequently backed up) repository, just one virus or system failure on a developer desktop may destroy the only copy of critical project files, potentially causing major project setbacks.

An effective configuration management policy involves the definition of guidelines for configuration management system usage, and then the implementation and integration of those guidelines (along with supporting technologies and configurations) into your software development lifecycle to ensure that your teams apply the policy consistently and regularly. It also requires a means to monitor and measure the policy's application as well as report the data it is tracking. Inconsistent usage compromises the effectiveness of source code control and, even worse, opens your project to file corruptions, lost work, misused resources, and ultimately project and/or production application failures.

Here are some suggested policies for integrating configuration management systems into the development process:

Each developer must have a sandbox with copies of files related to her current work

A sandbox is an area where copies of project-related files can be stored and manipulated without affecting the master source code base. Before a configuration management system is ever used, the team should establish a developer sand box for each and every developer. In addition, each developer sand box should be cleanly shadowed (for example, receive read-only copies of the master files stored in the configuration management system) from the configuration management system and cleaned after major revisions (see the policy "Each developer should clean the sandbox and re-shadow relevant files after major changes").

The build process must have a sandbox with copies of all files needed to build the application

Before configuration management system is ever used, the team should establish one build sandbox for each system that the team needs to build. The build sand box should be cleanly shadowed (for example, receive read-only copies of the master files stored in the configuration management system) from the configuration management system and deleted on a daily basis.

Each developer must check out only code which she is actively modifying

Before a developer can modify a file that has been "shadowed" to her sandbox, she must "check out" that file from the configuration management system. Once a file is checked out, it is locked to that developer, and nobody else will be allowed to modify the file until the first developer "checks in" her changes (for example, adds the modified file back into the configuration management system and removes the revision lock). During any given day, each developer should only check out the files that she is actively modifying.

When a group member locks files that she is not actively modifying, she may be preventing other group members from modifying the files that they need to work on, and thus causing a development bottleneck.

Each developer must add to the configuration management system only code that complies with the required practices and passes the designated quality checks

As soon as a developer is certain that new or modified code satisfies the designated quality guidelines, she should add that code to the configuration management system. When developers work in this way, the only code that is not available in the configuration management system is the code that a developer is actively modifying.

These first four configuration management policies are illustrated in the following figure:

Each developer must clean the sandbox and re-shadow relevant files after major changes

After significant structural changes are made to the directories shadowed in a developer's sandbox (for example, many files are added, removed, or renamed), it is a good practice to remove all files from the sandbox, and then reshadow the code. This ensures that the sandbox is synchronized with the related area of the source code repository.

The build sand box also undergoes a similar cleaning to ensure that it too stays synchronized with the main source code base.

The entire team must store code for different software versions in physically independent configuration management systems

Once the code for a software version receives the stamp of approval, it should be physically separated from the working code base and placed in an independent configuration management system. By physically separating the code base for each "final" software version, it removes the possibility for day-to-day source code modifications to impact "final" versions of the software, and also prevents any emergency fixes to that "final" version from affecting the current version. When a version is no longer supported, the entire configuration management system for that version should be archived and stored.

For instance, assume that the team just completed version 2.0 and is now ready to modify the code to add new features for version 2.1. Before modifying any code, the complete 2.0 code base should be placed under an independent configuration management system. This allows for the ability to reproduce and-if necessary-modify the true version 2.0 code base.

Not following this practice can yield two serious risks:

If a file is fixed in the old version of the software, it could cause unexpected side effects in the current working version of that software.
As the files are modified in the new version of the software, the changes could impact the old versions and it might be difficult to determine exactly what code is being used in the old versions.

The entire team must use versioning features only for slight variations within one software version

Many developers are under the impression that versioning features allow them to safely work with and modify different versions of code. But what they don't realize is that errors may occur because modifications are sometimes made without paying any attention to which version they are trying to fix. A developer may fix a problem in one version, while creating numerous errors in another version.

These versioning pitfalls can be averted by moving each completed software version's code base into an independent configuration management system, as described in the preceding policy "The entire team should store code for different software versions in physically independent configuration management systems."

Although versioning features are typically error-prone when used to separate code from different sequential releases (for example, 2.0 from 2.01 and 2.1), versioning features could be useful when there are minor differences in a software version (for example, different versions- with slightly different files- for different devices).

The entire team must always avoid the parallel development feature

The Parallel Development feature in many configuration management systems allows two developers to work on the same file simultaneously. After the developers make their modifications to this file, they check it back in, and the system is supposed to merge the modifications. However, this is a completely and utterly useless feature of version control systems. In fact, Parallel Development has probably created more bugs in the industry than anyone can count because in reality, the system is merging two very different pieces of code that were modified without regard for each other. Therefore, this feature should be blocked from the configuration management tool, and establish guidelines that allow code to be modified by only one developer at a time.

Dr. Adam Kolawa is cofounder and CEO of Parasoft, a vendor of automated error-prevention software and services based in Monrovia, CA. Dr. Kolawa, who is the coauthor of Bullet-proofing Web Applications (Wiley, 2001), has written and contributed hundreds of commentary pieces and technical articles for publications such as The Wall Street Journal, CIO, Computerworld, Dr. Dobb's Journal, and IEEE Computer. He has also authored numerous scientific papers on physics and parallel processing. He holds a PhD in theoretical physics from the California Institute of Technology.

Set as favorite

Bookmark

Email this