Basic Theory of Configuration Management
The goals of using CM are to ensure
the integrity of a product and to make its evolution more manageable.
Although there is overhead involved in using CM, it is generally
agreed that the consequences of not using CM can lead to many problems
and inefficiencies. The overhead of using CM relates to time, resources,
and the effects on other aspects of the software lifecycle",
Susan Dart, CMI.
Many people falsely believe Source Code Control tools or
Automated Configuration Management to be a silver bullet for curing
all software development ills. However, implemented properly, it
can increase the effectiveness of your development and maintenance
efforts and lead to better software, and reduced costs.
Lets begin at the beginning. The terms Source Code Control and
Configuration Management, are often bandied about, but what do they
mean?
Traditional Source Code Control
When many software developers think of SCM/CM they think of of
traditional SCC,
- Source code is checked in/out
- One or more developers can check out a file
- Rule based Merging of source code
- Basic archive kept of previous versions.
Tools like CVS and PVCS VM fall into this category. Whilst PVCS
VM does have some higher end CM features, it is still primarily
a SCM tool.
Configuration Management
Configuration Management takes a much broader look at the process
of developing software. The degree to which a particular tool implements
CM features varies greatly, however they include:
- Dynamic and insulated views / work areas
- Work flow automation, including online bug reports, and audit
controls
- A developer is kept informed of changes relevant to the area
in which they are working by e-mailed or other means.
- Changes may only flow from one view to another under defined
rules (e.g.: after sign off, code review etc.).
These features make implementing source code control much more
worthwhile for the software developer. Allowing each developer to
create software in an insulated work area, updating with outside
changes at their discretion leads to a much better working environment
than one where one developers 'build' is constantly being broken
by another developers 'fix'.
With CM developers work on checked-out versions of objects to
prototype, edit, build and debug before making their changes available
to other developers, without being isolated from the development
process.
- references:
The
Beginning to your CM Solution, Nadine M. Bounds, Susan Dart.
Configuration
Management Frequently Asked Questions, Version: 6.7c
|
