Vaccaperna logo

 

Services
Articles
Testimonials
Contact us

 

Choosing an SCM (Software Configuration Management) tool

This article has been translated into Serbo-Croatian by Jovana Milutinovich from Webhostinggeeks.com.

 


 

Introduction

 

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.

 


 

Process then tool

 

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 thoughts on process

 

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.

 


 

Requirements

 

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

 


 

Platforms

 

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?

These days Windows and *nix platforms cover most requirements, but a less common platform such as OpenVMS or AS/400 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).

 


 

Costs

 

There are free open source tools and there are those costing $6,000 or more per seat with lots of others in between. The open source tools include CVS, Subversion, and increasingly a range of distributed version control tools (DVCS) such as Git, Mercurial, Darcs and Bazaar.

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.

Be aware with the open source tools that they will cost you in time and effort to support them. It is worth considering this in relation to commercial tools. Some larger companies use open source tools and then spend money paying staff to work on the tools and implement features the company is interested in. This sort of model is becoming quite common.

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 increased cost!

 


 

Performance

 

 

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.

 


 

Reliability and support

 

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 support

 

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.

 


 

Process support

 

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).

 


 

Provide support for remote sites

 

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).

 


 

Client/server architecture

 

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.

 


 

Transaction based updates

 

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.

 


 

Integration with Microsoft Developer
Studio or other IDEs

 

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.

 


 

Integration with other tools

 

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.

 


 

Scriptable

 

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.

 


 

GUI front end

 

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?

 


 

Ease of use

 

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.

 


 

Commercial

 

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?

 


 

Other Functionality

 

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)?

 


 

Conclusion

 

Choosing an SCM tool takes time and effort, and the results will depend on that. Engaging the services of a consultant (such as me!) can help reduce the time and effort considerably and ensure you avoid wasting time and effort, and spending money on a tool which doesn't meet your needs. Contact us for more information.

 


 

Resources

 

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.cmcrossroads.com is the premier resource on the web with active forums and lots of participants. This site is also the home of the Configuration Management Yellow Pages with a comprehensive list and summary of vendors and tools, and CMWiki.

In addition there are a variety of groups interested in the subject area on www.linkedin.com.

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