One of the most common questions that I have been getting recently has been "what source control provider do you use and why?". This article is the first in a series of two articles about source control. This article takes a quick look at criteria that I believe is important to consider when it comes to evaluating source control systems for use. The next article in the series will be a review of the source control system that I use, in relation to the evaluation criteria that I list in this article.
Overview
First of all, as you can imagine selecting a source control system is a big decision, once you go down the road of implementing a specific solution it is often hard to make a change later. Regardless if that difficulty is due to incompatibilities between system, or the massive level of effort needed to switch to a different provider. Due to this, I find that it is very important to take a methodical approach to select the source control provider that you will use. As part of this, it is also important to take stock of your current situation as well as to forecast what your situation will look like with future growth, as that can play a major role in what solution to go with.
Why Use Source Control?
However, before I dive into the criteria that I use to evaluate source control systems, I want to take a quick moment to express the importance of implementing source control. I have heard many arguments from individuals as to why they don't need a source control system. Some of my favorite ones are; I'm the only developer, we only work internally, and it's too expensive. All of these statements are entirely untrue. Source control systems provide many things to a development team, and the information stored within can be used in various ways to help provide input to a situation.
The primary usage is to track changes, with discipline and a proper environment configuration you can be assured that every change to code on a project will have a comment. With a bit of education in your development teams you can ensure that these comments provide you historical information that indicates the reason for the changes, and any other details determined necessary. Additionally, the ability to look at previous versions and do comparisons takes it to the next level in regards to identifying WHEN something was introduced to a system. This information can help produce accurate security briefs or other notifications should a security vulnerability be found in your code, you can quickly identify affected versions. There are many other reasons that justify why source control is important, I just wanted to take a quick look at this before discussing my evaluation criteria. The evaluation criteria that I use is broken into four major areas; Visual Studio Integration, Team/Remote access, Backups/Restores, and other features. The following sections will go into each of these.
Visual Studio Integration
For me, one of the most important considerations is the level of integration into Visual Studio. Since VS is my primary development tool, I really don't want to be forced to leave Visual Studio to perform check-in or check-out operations. I want full access for regular operations as well as the ability to see my history, perform difference checks on files and overall manage the source control system from within my project.
From a productivity standpoint, I see this as a huge benefit, if you can reduce the need for an individual to use multiple tools you can dramatically improve their performance, AND it makes it much easier for an individual to get in the habit of working with Source Control
Many of the providers out there have Visual Studio integration components, some install with the system, others are added 'ons that you must download on their own. The key is to understand what you can and cannot do from within the Visual Studio IDE.
Team/Remote Access
Another huge thing for me is the ease of use when working in a team environment, especially a distributed team, or in a location where you must do development from multiple physical locations. In this category, I have two key things that I look at. The first is obviously the licensing model, how much is it going to cost me to implement this system for my current team, what about in the future as we grow. There are some providers out there that are free, others charge per user, others charge per active user, and some provide site licensing. A key to properly understanding the "right" choice here is to fully understand the impacts of the pricing model, and the ability to change if needed.
The second part of this is the remote access component. The usability and existence of a source control system that exposes a web interface can be a major selling point, especially with remote developers. For example, in my situation, with doing development at home and in other locations, I had to have a system that could be made available over https so that I could access it from any location. And the performance of this system must be adequate especially when working with larger files. This is one of the key areas where you will see varying reviews between providers.
Backups & Restores
In my opinion, another key evaluation criteria are the ability to easily perform backups and restore, and to work with those items on your own. I, for example, select a system that uses a SQL Server database to store all documents, versions, notes and similar information. I can do a regular backup of this system easily by simply keeping a backup of my SQL Server database and everything needed is contained within. Other source control providers might use different methods of storage, it is important to understand how this works, so that you can come up with a proper system to perform backups and restores in a manner that will not cause an issue.
Other Features
This final category is where I lump in a lot of the other "extras" that are sometimes associated with a source control system. SO these items are things such as the ability to assign blame or to associate a change with a specific bug. These types of features are ones that I don't know as much about, as I do not utilize my source control system for bug tracking, it is simply an application versioning system. Depending on your organizational goals, however, these features could be of great benefit. I'm sure there are a number of other things that could be used to evaluate products as well.
Conclusion
Overall I hope that this article has at least sparked some thought in regards to what is needed to select a source control provider. Feel free to share your list of evaluation criteria below, it is great to hear other feedback as well.
The next article will be a review of the source control provider that I use and a quick explanation as to why it won the opportunity.