Source Code Control 101

At work, we're moving toward a more standardized development process. Part of that standardization is on the usage of SourceSafe for source code control, and CruiseControl.Net for continuous integration (CI.) The developers on the team come from a variety of backgrounds, and have different levels of experience with CI. As the resident Build Guy, I've spent the most time with the tools and decided to lay out my thoughts on the process.

*Note that these are not the only tools available, and with SourceSafe in particular there are certainly better options. These are simply the tools we are working with.

*Note also that I intended to cover both SS and CC.Net in a single post. It ended up a bit longer than expected, so I'm splitting it into two entries. This post is limited to source code control. The next will dig into continuous integration.

SourceSafe as version control

SourceSafe is not merely a way to back up code in case of hard drive failure. It is a way to revision your code. It allows you to define checkpoints in completed work. It provides an easy way to compare changes and roll back work if you find yourself going down the wrong path.

For example, let's say you're updating a desktop application. The current app generates a text file as output. The goals for the next release are to enhance the logging and to generate xml instead of plain text. To start, you decide to replace the existing log with xml. Looking at the code, you realize the log messages are scattered throughout the entire app. Unless each message is to be a self-contained element, this makes it difficult to generate well-formed xml.

So you begin by creating a custom logger class. This lets you track where in the xml tree you are, and ensures the output is well-formed. After you've finished testing the logger, it's time to replace all of the old logging code with calls to the new class. Right?

Not just yet. Now that you have working code it needs to be checked into SourceSafe. "It doesn't do anything yet," you say? True. However, even though the class isn't used, it's still a functioning piece of code. If you have to switch projects now, you know you can come back later and pick up with a working app.

"What if you need to make a bug fix and release to production?" The code isn't being used, remember? So there shouldn't be an issue.

With the logger checked into SourceSafe, it's time to replace the existing logging code. At the start, everything seems fine. But several hours into the process, you realize something. It appears there's a bit of rarely-used code that logs info in a non-trivial, non-standard way. No problem - you can update the xml logger to deal with the new info. A few changes, which you of course check into SS, and you're back to replacing code. But shortly thereafter, for whatever reason, you realize the logger changes shouldn't have been made. Now what?

Fortunately, the previous revision exists in SourceSafe. It's easy to roll back the code and continue with your work. But say you hadn't checked in the changes? Instead, you would have had to manually modify the code until you were back to the point you were before. If you've ever tried this, you know it's not often a trivial matter. It certainly takes longer than the minute or two required for a SourceSafe rollback.

SourceSafe allows collaboration

Most software projects involve several team members contributing code. This requires some means of getting updated code to the other developers. It may also require a new developer to come in and pick up where another left off.

Going back to the xml logger, say you have the logger code checked in and are pulled off to work on another project. A new developer comes in and is tasked with replacing the old log code. All the new guy has to do is get latest from SS and he can continue right where you left off. Or maybe he comes in at the point where you've added to the logger (just before you realized those changes weren't necessary.) Once the new guy figures out what's going on, it's as easy for him to roll back the code as it would have been for you. There's a clear snapshot of where the code was before the change.

Checkin frequency

So you now see a few benefits of source code control. The next question you may have is "How often do I check in my code?" It depends on what you are doing, but the general answer is "Often." A few times a week is typical, and multiple times a day is entirely possible. The key is to find stopping points throughout the project.

Say you start coding a new multi-tiered application. You begin by writing a few classes in the data layer, making sure you can connect to the database. As soon as you have these compiling and running correctly, check the code in. As you add new classes, check them in. There's no reason to wait until the entire layer is code complete.

Say instead you are working on a desktop application. You begin by placing a few controls on a blank form. Maybe you hook those controls to business logic. Or maybe you prefer to setup the layout before making the code do anything useful. Either way, each piece of logic and each set of controls define a discrete unit of work. Hook up a couple buttons and check the code in. Add logic to traverse the local hard drive, then check the code in. With a bit of practice, you should recognize several good checkin opportunities on any given day. That's not to say you need to check code in this often, but once a day is certainly possible.

One final thought - before checking in the code, make sure it compiles and runs on your box. Checking in code that doesn't compile only hinders development. I'll cover this next time when I introduce continuous integration using CruiseControl.Net.