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.
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed
