|
Software Configuration Management (SCM)
What is SCM? | SCM processes | SCM links on the web | Branching patterns
 
Our favourite definition of Software Configuration Management is:
The most frustrating software problems are often caused by poor
configuration management. The problems are frustrating because they
take time to fix, they often happen at the worst time, and they are
totally unnecessary. For example, a difficult bug that was fixed at
great expense suddenly reappears; a developed and tested feature is
mysteriously missing; or a fully tested program suddenly doesn't
work. Configuration management helps to reduce these problems by
coordinating the work products of the many different people who work
on a common project. Without such control, their work will often
conflict, resulting in such problems as:
Simultaneous Update
When two or more programmers work separately on the same program, the
last one to make the changes can easily destroy the other's work.
Shared Code
Often, when a bug is fixed in code shared by several programmers,
some of them are not notified.
Common Code
In large systems, when common program functions are modified, all the
users need to know. Without effective code management, there is no
way to be sure of finding and alerting every user.
Versions
Most large programs are developed in evolutionary releases. With one
release in customer use, another in test, and a third in development,
bug fixes must be propagated between them. If found by a customer,
for example, a bug should be fixed in all later versions. Similarly,
if a bug is found in a development release, it should be fixed in all
those prior versions that contained it. In larger systems with
several simultaneous active releases and many programmers working on
bug fixes and enhancements, conflicts and confusion are likely.
These problems stem from confusion and lack of control, and they can
waste an enormous amount of time. The key is to have a control system
that answers the following questions:
- What is my current software configuration?
- What is its status?
- How do I control changes to my configuration?
- How do I inform everyone else of my changes?
- What changes have been made to my software?
- Do anyone else's changes affect my software?
'The key role of Software Configuration Management (SCM) is to
control change activity so these questions can be answered. If,
however, SCM is viewed merely as a management tool or contractual
obligation, it can easily become a bureaucratic roadblock that
impedes the work. While such systems may be contractually required,
the real need is to assist the programmers in controlling and
tracking their work, while ensuring that nothing is lost or
destroyed.'
Watts Humphrey, Managing the Software Process
(Addison-Wesley, 1989)
There are a number of other definitions maintained by Brad
Appleton.
From Vaccaperna's recent work, for example in the mobile phone
customer care and billing market, it is clear that many organisations
still have problems really getting to grips with SCM - its importance
is usually recognised but the practical implementation is frequently
poor.
It is interesting to see the divide in the tools market between the
"process driven" tools and the others. This divide can be more
artificial than real, in that an effective process can be designed
around a variety of tools. The key is in the implementation, which is
where Vaccaperna applies its knowledge and experience of the software
development process across a number of industry sectors.
It is vital to implement a process that achieves control but does not
leave developers feeling they have to go through layers of red tape
to get the smallest thing done. With experience, planning, and the
use of a powerful yet inexpensive tool such as Perforce, 20% of the
cost can reap 80% of the gains in properly controlled software
development.
The first ports of call are:
SCM FAQ from comp.software.config-mgmnt newsgroup
SCM Yellow Pages
There are a couple of excellent papers. The first is written by
Perforce but is generic in nature and well worth reading: High Level Best Practices.
The second is the excellent set of branching patterns written by Brad
Appleton and others: Streamed Lines - Branching Patterns for Parallel
Software Development
Back to the top
Contact us
© Vaccaperna Systems Ltd
|
