On April 30, 1999 U.S. taxpayers lost over 1.2 billion dollars due to a small mistake in software configuration management. It was on this day that a Titan IVB rocket was scheduled to put the U.S. Air Force’s most advanced communication satellite into orbit. The Titan rocket track record includes over 300 successful launches, but on this day the Titan failed to deliver the satellite into the desired orbit at 22,300 miles. Flight controllers had to put the bird into an ineffective elliptical orbit of 2,781 by 592 nautical miles, drain the electrical power, and disable all functions before the satellite ever performed service.
Why did this happen? Because somebody forgot to put a parameter file under source control and the file was lost. When an engineer modified a similar file to recreate the lost file, an engineer typed in a value of -0.1992476 instead of the correct value: -1.992476. This small error meant an 800 million dollar satellite and a 400 million dollar rocket launcher produced zero payoff. Fortunately, for the majority of us, the cost of not using (or misusing) source control software will be orders of magnitude smaller, yet the cost is still there.
What is Source Control?
When I first saw a source control tool, I thought the purpose of the tool was to enable a team of developers to work on source code without overwriting each other’s changes. While a source control system does enable this scenario, there is much more to these tools known as source control or version control systems. In the rest of this article, we will provide an overview of the basic features common to source control systems and how these features work in the software development process.
The Repository
All source control systems will feature a repository where we store source code and other files related to the software product. Developers will retrieve source code from the repository, make changes, and check the source code back into the repository (as well as add all new files to the repository).
The repository not only stores files but also tracks the changes to each file as developers check in new versions. You can go back and look at the history of any file in the repository to see what changes have occurred. Sometimes just knowing what has changed since yesterday can help you track down an elusive bug that appeared today.
Perhaps if an engineer had checked in the parameter file, the Titan mission would have been successful – it’s hard to say with 100% certainty, but I am sure the odds would have been better. Likewise, you can risks to your software project dramatically by keeping the asserts needed to build the product in a repository. The repository should be a secure machine with regular backups, of course.
Labeling
NASA has a saying: test what you fly, fly what you test. To a developer this saying should resemble: test what you deploy, and deploy what you test. Source control is just one of the tools used to manage software in such a way that you always know what you are deploying, and testing. The quality of your software will benefit.
Labeling, also known tagging, is a feature of source control systems that allows you to apply a friendly name to a specific version of a project or set of files. It is a good idea to label files every time a product is built, perhaps with just the name of the product and an auto-incremented build number (WhizzBang.1286, for instance). If a problem is found in test, you can go into the repository and identity the exact set of files used when the software was built.
Another great time to apply a label is whenever you deliver your software to the outside world. Say build 1286 of WhizzBang has passed all the testing and is ready to deliver to customers. You can apply another label to this set of files, perhaps “Whizz Bang 1.2” if you’ve already delivered versions 1.0 and 1.1. Perhaps six months later one of your customers calls with a severe bug report for version 1.2. Fortunately, you know exactly what you’ve deployed to the customer because the files were labeled. A developer can retrieve all the files labeled “Whizz Bang 1.2” and reproduce the problem.
Branching
Another great feature of source control is the ability to ‘branch’. Think of every developer always pulling the latest version of code from the repository, making changes, and checking these changes back into the repository. The latest version of the files represents the “trunk” of the source control tree. Sometimes it is necessary to branch off of the tree to perform parallel development on the product.
For instance, suppose you’ve identified the problem in Whizz Bang 1.2 and now need to get a fix to the customer. You could apply the fix to the latest version of the code (the trunk), but the rest of the product may not be in a good place for deployment. Perhaps you are one month into a three month project plan for version 2.0 and many new features are still incomplete. You can’t send an incomplete version to the customer, so you can’t build the latest version as a fix.
In this scenario it is prudent to apply the change to the stable version labeled as version 1.2. Source control will allow you to branch the main tree at the version 1.2 label. While some developers begin to work on delivering version 1.2.1 from the branch, the rest of the team can continue working on the main trunk to finish 2.0 features. A good source control system will automatically merge changes made on a branch back into the trunk, in effect putting the fix in for 2.0 also.
The scenario above is just one example of using branching. Branching is a powerful feature and there are many different ways to use branching to meet the style of your development.
Source Control While Flying Solo
Perhaps you are a solo software developer or just experimenting at home with some code. If you’ve read this far, hopefully you’ve already realized that source control isn’t just for big development teams. How many times have you started to make massive changes to a code base, but after an hour decide you don’t like the approach and wish you could roll back to what was working before? If you are using source control this is an easy step.
It is also advantageous to use a repository for storing all of your code, and backup regularly. Tracking history, versioning, and labeling are all there to take advantage of.
Source Control Now!
There are source control products available to fit any size project and budget. If you aren’t using source control today, I hope this article has convinced you to start using source control tomorrow. Once you’ve started using source control you’ll find it to be just like oxygen. You won’t notice when you have source control in place but you’ll be hurting if it’s not present.
Subscribe
Twitter
Search
About
Learn C#