|
Choosing an SCM (Software Configuration Management) tool
 
Selecting an SCM tool is not a trivial exercise in most cases. It
requires thought and planning, and preferably sufficient time to
investigate and consult other people, especially if you don't have
much experience in this area.
This document gives some thoughts and guidelines to help you on your
way. Please email comments to
In short:
- decide on your requirements
- collect information
- evaluate using your own scenarios
- decide!
If you do not have much experience then consult experts and other
users (reference sites), try the newsgroups. Find out what works for
other companies, preferably as similar to you as possible.
An SCM tool is only part of the software development processes of a
company, and must fit in with other practices, and indeed the
corporate culture.
It's often referred to as "Process then Tool" - define your process
first before choosing a tool. There are those who add "People" to
Process - make sure your processes support the people who are going
to work with them.
No tool is going to magically allow a badly defined process to be successful.
However, tools and their capabilities are going to feed back into
what processes are possible or easy to implement, so decisions are
not made in isolation. This is an area where experience in
implementing an SCM system will help substantially in being able to
map general principles to specific instances, and make appropriate
tradeoffs.
Thus I do not believe you can make a pure process decision first and then decide
on the tool. For example, budget will often rule out the "high cost" tools, even
if you would like to have them due to their capabilities to support your desired
process. This is just a fact of life - you have to do the best you can within
your specific constraints!
Some people like very rigorously defined processes where people are
not allowed to shortcut the process at all. Others enforce process by
asking people nicely to do it, training them (and providing backup
documentation), and if they don't do it you can always beat them up
after the fact! (or have a notice board with transgressors of the
"never break the build" rule available for all to see - works for some
open source implementations).
But, in any development process,
there are likely to be some rules that must be followed or major problems are
likely to result (e.g. always building release versions of code from
controlled sources).
If you prevent process being got around with tool support then you
need to think what happens when changes are required very quickly, or
the only person able to authorise a change of state is away or busy.
What will your developers do in such a situation? Do you have an
emergency process? The danger is that, if the process is too rigid
and bureaucratic, then developers are going to be tempted to
side-step it, and you will be worse off than with no process. People
circumvent processes which affect their ability to deliver their
objectives.
In our experience, the best guideline is to go for the lightest
weight process that works reliably and fits your constraints. Judging
this is a balance between company culture, the people in the team,
personal experience and personal preferences.
Why not try designing an emergency release process and then produce
all releases that way - make it easier for the developer to follow
the process than to circumvent it.
Having defined, or at least got an idea of, your process this will
feed in to a list of requirements to help you whittle down the
potential tools.
Some categories of requirement are:
- Platforms required
- Costs
- Performance
- Reliability and Support
- Branching and merging support
- Process support
- Support for remote sites
- Client/server architecture
- Transaction based updates
- Integration with Microsoft Developer Studio or other IDEs
- Integration with other tools (e.g. defect tracking)
- Scriptable to enable automation of tasks
- GUI front end
- Other functionality
- Easy to use so that documentation and testing teams could use the product
While some organisations do use different tools on different
operating systems, it is better to be able to use the same tool on
all the platforms you are working with.
How good is the support for the various platforms? Some tools offer
GUIs only on Windows - is this a problem?
A less common platform such as OpenVMS is going to restrict the
choice of tool significantly (which can actually make your life easier - since
you rule out tools which don't support it).
There are free tools (RCS, CVS) and there are those costing $6,000
or more per seat with lots of others in
between.
Note that per seat costs are not the only things you need to worry
about - consider extra modules, hardware and other infrastructure
costs to support the tool, and also administrative costs - both for
implementation and ongoing support. These can vary dramatically.
Consider TCO (total cost of ownership), and make sure that any third
party licences (e.g. database licences) are included.
For some organisations, the costs will immediately rule out the
higher end tools.
In any case, you need to have an idea of your budget, and investigate
carefully to ensure that you have identified all the likely costs.
You need to also be aware of future costs. I have heard of several cases of what
is known in the UK as "stiffing". The vendor gives you an excellent price on the
initial set of licenses you buy. However, some time later you look to upgrade
either the number of licences or perhaps to upgrade your support contract. At
this point the vendor charges the "list" price, or will only offer you the
upgrade if you move from their "standard" to their "enterprise" version at a
dramatically increase cost!
What is fast enough for your application? Frequently you need to do
your own evaluation to satisfy yourself of this one. How many files
and objects are being copied around your system? Are you controlling
a few hundred or many thousands of files? Are they a few megabytes or
many hundreds?
Some tools are very sensitive to network performance, others
substantially less so.
Performance will also be affected by things like the requirement to
work remotely or over a WAN.
Controlling larger web sites, with hundreds of thousands of items, is
definitely a challenge for most SCM tools. You need to insure that the tool your
are looking to use has been tested with the volumes you intend to use.
A subjective one, but it is possible to get a feel for reliability
and support by asking questions on newsgroups or user groups.
Get and take up customer references, and get a feel for how happy current
customers are with the product (fairly easily done via mailing lists).
Branching and merging is required for things like parallel
development with more than one release of a product going on at the
same time. Without good support for this in your tool you will waste
a lot of developers time.
Note that some tools use branching and merging to implement
process.
There are some excellent resources on branching, in particular the Branching Patterns for Parallel Software Development
paper.
This can be provided in a number of ways:
- integrated support with a GUI for drag and drop process definition
- out of the box process with customisation options
- scriptable process support
- none!
Which type of process support you prefer (and are prepared to pay
for) should be part of your evaluation.
GUI process definition has definite advantages if you require process
to be implemented, but scriptable (with lots of hooks) is the most
flexible (although may require debugging).
Do you have remote sites working on the same source code? How are
your links to those sites?
What options are available in the tool to support what you want? This
can range from good performance over TCP/IP making remote access to a
central repository viable, to fully distributed depots (at a not
inconsiderable cost).
With the older tools such as RCS, the client program is directly
manipulating the archives of files, and these are therefore subject
to inconsistency problems if say the client workstation crashes (or
network connection fails) during an update.
True client/server architecture tools are less susceptible to this
sort of problem, although the reliability must be designed in - see
transaction based updates below.
All "modern" tools are client/server and I really wouldn't advise any tool which
does not use this model.
This is related to the client/server architecture - some tools offer
the equivalent of database transactions such that a set of
modifications to the repository either all happens or none of it
happens. A potentially very useful feature.
When you are reviewing a previous change to a file to find out what was modified
and why, it is very useful to be able to find out what else was changed as part
of the same bug fix (checked in as part of the same transaction). Having to do a
search on files checked in about the same time and by the same person with the
same checkin comment is more difficult than it might be.
Whatever IDE (Integrated Development Environment) your developers are
using, there should ideally be an integration with the SCM tool so
that the user does not have to exit out to run the tool but can just
right click or whatever and check files in and out.
Most tools on Windows support the Microsoft Common Source Code
Control (SCC) interface (via a DLL), which at least provides basic
integration.
Some tools provide their own interfaces to a wide range of developer
tools and on different platforms.
Micrsoft have really taken a step backwards with Visual Studio.NET and its
support for SCC - the performance is frequently much worse than VS 6. However,
you need to check this for the tool you are considering.
Some tools are "all inclusive" with their own built-in defect
trackers and build management systems, other tools are not.
Do you already have a defect tracking solution and will the tool
integrate with it?
Like most things, some of the integrated tools are not necessarily
"best of breed" in their SCM functionality but make up for it with
the integration. Which is most important for you?
Another set of tools that you should consider are the build
management tools. How will the SCM tool interface with your favourite
tool, be it Make or whatever? Some SCM tools come with their own Make
equivalents which can track objects built using the same sources and
compiler switches and avoid rebuilds across a network - potentially
quite a time saver.
Tools which always require you to press buttons on a GUI are not a
good idea. If it's scriptable (via a command line interface) you can
automate a number of tasks and hide details away from people who
might otherwise need training in how to use the tool (e.g. testers or
documenters).
This is vital to be able to take advantage of practices such as agile
development with associated continuous builds and integration.
This is related to platform issues, but most tools have a GUI front
end which is what the majority of developers these days use. How good
is it? How easy is it to pick up?
Have a look at the web sites, get an evaluation and try out a few
things - the only good ways to judge ease of use. Make sure you
include this in your evaluation scenarios.
Is the vendor financially viable and going to be around for the life
of your use of the tool? Are there any plans for the tool to be
discontinued? Is the vendor a likely takeover target and what plans does any
acquirer have for the long term support of the tool?
Consider items such as:
- whether the tool versions directories (and if you need this).
- how does the tool handle user permissions and security?
- how are specific file types stored (e.g. symlinks)?
All the vendors are on the web - their web sites will tend to give
you a slightly biased view but still contain a lot of information.
The site www.cmtoday.com is a useful resource with a
mailing list you can sign up for and ask questions on. This site is
also the home of the Configuration Management Yellow Pages with a
comprehensive list and summary of vendors and tools.
The other major resource is comp.software.config-mgmnt newsgroup. Post a question on this and you are bound to get quite a few helpful replies. In addition you can search it using
Google Groups.
There is a report from Ovum (www.ovum.com and search for Configuration
Management) which evaluates a number of products in some depth (at a
cost of around $2,000). They say in the report that it is an example
of how to do evaluations rather than a recommendation for particular
products - don't buy it expecting to have a decision ready made for
you!
Please send feedback and comments on this page to
and it will be improved!
Back to the top
Contact us
© Vaccaperna Systems Ltd
|
