Managing Source Code

[ This post is the first post in the Managing Source Code at 8BIT series. ]

For one reason or another, budding developers tend to shirk the responsibility of source control until it’s too late. Motivation for putting a system in place usually occurs when:

• Another person has joined the team and it’s difficult to track who is working on what
• Code is overwritten and can’t be reclaimed
• Days were spent working on a feature for a client that completely misses the mark and it’s not impossible to rollback to previous state.
• A hard drive fails and the entire codebase is lost

Sure, there are other scenarios but the above are not at all uncommon.

When it comes to source control, I take a pretty strict stance: If you’re a large team, small team, or a one-man team, then all of your code should be kept in a source control system.

This is especially true if you’re working on a product that you’re planning to sell or if you’re working on a product for someone else.

In fact, the first thing I did when joining the team was put source control in place. Over the next few posts, I’ll share our current process, how it came to be, and where we’re headed in the coming year.

But first, a quick heads up on source control…

If you’re new to source control then think of it as a way to track of the history of each file that make up your project. It allows you to update, rollback, view history, and eventually tag releases of each version. Simply put: You have a snapshot of every component of your project at every single point in its lifetime from everyone that’s contributed to it.

If you’re writing code and not using source control, you’re gambling. Source control is one of the most effective tools in a professional developer’s toolbox.

If you’re not using it, there are several free options available:

• Beanstalk
• GitHub
• SpringLoops
• Unfuddle

When it comes to source control systems, developers are opinionated. Get a handful of them in a room and ask them to explain why they love and/or hate CVS, Subversion, Git, BitKeeper, Mercurial, or any other system under the sun and you’ll leave that discussion no better off than when you entered.

Determine the needs of your team, do some research, and pick a platform. Don’t over think the process. There’s no silver bullet solution. Sure, some options are going to be better than others for your given workflow, but the main goal is to start versioning your code.

As your team begins to use the system, its strengths and weaknesses will shake out and you’ll know if it’s working or not.

In this case, having something is better than nothing. Besides, you can always import your code into a new system later. In fact, 8BIT is about to move from our primary platform to another at the end of the year and it will be the second time we’ve changed providers.

In the next post, we’ll take a look at how we manage our development and releases using our source control systems. We’ll also look at what we’ve used, and the why and where we’re moving.