Do you really use Source Control? I’m not talking merely about having some code in a version control system. I’m talking about using source control as an efficient tool in your daily work. As a huge fan of the Joel Test I’ve put together my own 6 point test of source control usage:

The Anders Source Control Test

1. Is all of your code under source control?
2. Do you commit all of your changes, having your local copy and the repository completely in sync?
3. Is your source repository the master version of all code?
4. Do you know exactly what code revision that was used to build every single copy of the software deployed in production?
5. Can you make a bug fix to an old release and deploy it, without having to upgrade to the latest version?
6. Are all developers in the team comfortable with occasionally reverting all their working copy changes?

If you get 6 points you are definitely using source control. 5 points might do, but 4 or lower means that you are not using source control right.

Is all of your code under source control?

All code should be commited to source control. I have seen many projects that have kept the C# code under source control, but not the database schema – including stored procedures containing business logic. The database schema is code too. It has to be in the version control system. K Scott Alen has written a great article with Three Rules for Database Work that every developer using databases should read. The three rules are:

1. Never use a shared database server for development work.
2. Always have a single, authoritative source for your schema.
3. Always version your database.

I’ve mostly used Visual Studio Database Projects to version control databases. Unfortunately they are only available in Premium and Ultimate editions of Visual Studio. In my latest project we’ve switched to giving EF Migrations a try. It really doesn’t matter exactly how you version control the database, but make sure that for each revision of the code that is checked in there is also a compatible database schema checked in.

Do you commit all of your changes, having your local copy and the repository completely in sync?

Developers that are new to version control and team development sometimes keeps some files from being checked in. The reason is probably that they have made changes that they are unsure of or that some things are not ready to be committed yet. Either way it is a sign of using source control the wrong way. Using source control right means working on one thing at a time, checking in and refreshing the local code base before starting on something unrelated. If parts of the local code is kept outside of the commit there will sooner or later (probably sooner) be a case where some dependencies are missing, breaking the build of the checked in version. One thing that is unacceptable in any team environment is to check in code that doesn’t build (except when in private branches/workspaces).

Is your source repository the master version of all code?

The repository should be the master version of all code. The repository should be the one and only way to distribute the latest version code, database and other resources between developers. When making a deploy or install package, all the resources needed should be grabbed from source control. If something else is allowed to be the master (e.g. a shared development database) the source control repository will eventually become out of sync.

Do you know exactly what code revision that was used to build every single copy of the software deployed in production?

Every source control system have a system of tags (sometimes called labels). Set up a routine to always create a tag whenever code is handed off to someone outside the development team. Doing a small fix and deploying it to the test server? You have to tag it. When someone reports a bug it is absolutely crucial to know exactly what code version the reporter is running. If they are reporting a known bug that has been fixed you have to be able to check if they are running an old version without the bug fix, or if they are running a new version and just discovered that the bug fix didn’t work.

Can you make a bug fix to an old release and deploy it, without having to upgrade to the latest version?

During development or maintenance the latest version in the source control will probably be unstable, having features being only half completed and not yet tested. When someone reports a critical bug in a production environment you can’t make a fix based on your latest development version. You have to be able to grab the code that is run in production from a tag and apply a fix to that code base. Then you have to be able to deploy a new version with no other changes than the bug fix. Finally you have to make sure the bug fix finds its way into the latest development version as well.

If you have a good tag structure in place, you can create a branch from the tag of the production version, apply the bug fix in the branch, make a release from the branch and finally merge the branch into the development trunk/branch.

Are all developers in the team comfortable with occasionally reverting all their working copy changes?

Used right, the version control system is a safety net. I often refactor code. When refactoring I always start with a fresh copy pulled from the repository with no pending changes. Then I start refactoring in small steps. When I have fixed one thing and have a working version of the code I commit it. Sometimes I find out that one of my refactoring steps is a dead end. My great idea was flawed and I’ve just made a mess out of the code. This is where version control can save the day. It’s just to hit the revert button to get back to the latest committed version. An experienced developer will use the revert functionality occasionally. It’s not a sign of incompetence. It is a sign of quality awareness.

A manual revert (without using any diff tool support), trying to undo the changes in all code files and then starting on the next task will inevitably fail to revert some things. When the next task is checked in, the commit will contain totally unrelated changes that will just be confusing.

Summary

Using source control is not just a matter of using a source control tool. It is a matter of having the source control system at the centre of the development process.

How many points did you get? Less than 6? Then you have to improve.

Comments are Welcome

Please leave a comment if there is something you think is missing in the test, or something I’ve included that shouldn’t be here. It would also be interesting with comments with score examples from some real world projects.