Acquiring a New SCM Tool

Folks often ask "what is the best SCM tool" or "is there a comparison of SCM tools available." I would say that generic comparisons of SCM tools are sort of like generic comparisons of cars. Somebody looking for something that is fast and doesn't care about gas mileage probably wouldn't think much of a Prius.

Currently, IMHO, the SCM market is not a commodity market where the products are generally about the same. There is a wide range in both pricing and functionality. So, you really have to know your requirements and the priority of those requirements. A good initial priority to figure out is: which is more important to the organization; price or return on investment? There's no sense in looking at all of the tools on the market if there's not enough budget.

Generally, a good way to acquire a new SCM tool is to start from a well defined set of requirements, create a shortlist of 3-5 candidates that seem close, take a closer look and narrow that down to 2, and then do a proof of concept on those 2 and pick the 1 that most closely meets your requirements.

Depending on the size of the development group and the size of the company, acquiring a new SCM tool can be an eye-opening experience. Finding a tool that meets your requirements is perhaps the easiest part of the process. Some of the harder parts are: figuring out who all of the stakeholders are, getting all stakeholders to consensus on the requirements, getting upper-management buy-in, and securing the budget for the purchase. Getting budget and requirements to match is generally the hardest part and typically involves writing some sort of business case to justify the purchase.

Here are some typical stakeholders: CEO, CFO, Purchasing Agent, Legal, VP of Engineering, Director of QA, key developers, and Release Engineering. Some of these may seem to have nothing to do with SCM, but they do get involved in large purchases that affect the whole company. It is better to make contact with all of these folks early to get the full scope of what is required to change SCM tools so as not to get surprised later and potentially impact release schedules.

If you make a recommendation that fits the budget and best meets the other requirements, but there is still a big gap in the requirements, don't despair! If you've involved all of the stakeholders and built consensus, you have a good chance of leveraging that gap to increase the budget.

Act Like This is the Release

I think the single most important part of Release Engineering (RE) is the principle of "act like this is for the release." There may be times that this is too extreme, but I think that keeping this as a guiding principle will do more good than harm.

For instance, instead of having one process for developers to build during development and another one for release, try to use the same one. That way, when it comes time to release, the path is well worn and more easily reproducible if necessary.

That's hopefully a pretty obvious thing to do, but it isn't always obvious for developers. How many times have you heard "well, it builds for me, it must be your build scripts!" :-) The more closely integrated RE and development are, the better the chances of having a smooth and easily reproducible release.

IMHO, RE should pervade every aspect of development (to the level appropriate) and be involved from start to finish. Now that I think of it, this is akin to "test early and test often"; having QA activities/mindset pervade every aspect of development.

As to where the boundaries are between development, SCM, RE, I think that depends on the organization. However, when possible, I think it works best to have somebody with a big-picture view of all activities to be responsible for SCM/RE and for that to be their first priority. It seems to me that when this is given to somebody in development who does not have the big-picture and it is a second or lower priority, organizations run into trouble. By the way, by "big-picture" I mean somebody that is familiar with how development does things _and_ is very familiar with good release engineering practices and has done a variety of releases for different kinds of projects.

This may not always be possible, but the closer an organization can come to having RE/SCM be an important role (as opposed to an afterthought), staffed by somebody that knows when to branch, label, or lock, when to use parallel development, which SCM product is right for an organization, how to set up a good build system which integrates well into the release process, etc., the better off that organization will be. Of course, you may end up with some developers grumbling about how their freedoms have been restricted, but hopefully they will soon realize that a little more discipline is better than broken builds and long post-freeze settle times.