What Else Can You Do With Version Control?
If you've been developing software for any length of time, you more than likely use some sort of version control to safely store copies of the files that you're coding. We all know by now how incredibly useful it is to be able to trace the history of code you're working on, to be able to safely share it among multiple team members, and to be able to revert to a previous version in case of disaster. There are literally hundreds of version control systems out there; although we're a .NET shop, my team has settled on the free Subversion as our tool of choice in this area.
But whatever tool you use - Subversion, Visual SourceSafe, Perforce, the new Visual Studio Team System version control - if you're only storing your source code in your repository you're missing out. The key is to bring together three ingredients that are easy to obtain today:
- Version control
- Nightly (or more frequent) backups of your entire repository to a secure, distributed location
- Cheap hard drive space
What can you do with this combination? In the rest of this article, I'll give you five of my own favorite ideas.
The Dynamic Operations Manual
Our corporate operations manual, with details of such things as how to back up the e-mail server configuration, phone numbers for the hosting company, and so on, is a Word document stored in a folder in our repository. Right alongside it are various tools and scripts that are referenced in the document. When someone new comes on board who is expected to lend a hand in operations, it's a matter of moments to give them access to that folder in the repository, at which point a single checkout operation puts all the documentation and tools they need right on their local hard drive.
If someone spots a problem or omission in the manual, we encourage them to fix it in their local copy and then check the changes right back into the master copy. There's no need to maintain a formal change log in the document; we can always look at the version history to see who added what. And of course there's no risk. If something is wrong, it's easy to roll back to a previous version.
Naturally, you can apply the same principle to any set of tools or documentation you want to make easily available to people. For example, think about putting your employee manual along with whatever else new hires need to see into version control, or the setup files for the standard set of company utilities that everyone always installs when they set up a new computer. Install your version control client, sync up to the correct portion of the tree, and you're ready to roll.
If you've got a reasonably mature development shop, someone is writing specs for the code that you turn out. And inevitably, those specs need to be updated as the code is written. Priorities change, features get added and deleted, things get implemented differently than they're written, developers sneak in nifty new features that get added to the spec. Instead of letting the spec live as a document with revision marks, check it into your version control system and update it there.
Once developers and managers get used to having specs under version control, the next step is to transform them from documents into conversations. The key here is a version control system that supports some sort of update notification. Have all parties concerned sign up for notification when a new version of the spec is checked in. Then, if the developer has a question or problem, they can annotate the problematic part of the spec and check it in. The project manager gets notified that a new version is in the system and updates their local copy. A diff will show the new content (if this isn't an easy operation, you're using the wrong system) and the manager can set to work clarifying the spec and then check the fixed version back in. Lather, rinse, repeat.
If everyone uses this system, you can save time just in not having to dig through e-mail archives to figure out who said what and who made design decisions. It's all right there in the spec's own history.
Remember those distributed backups? It's worth spending time and even a bit of money to make sure you have automated backups of the entire repository happening on a nightly basis. In our case, we use Subversion's hotcopy capability to make a full copy of the repository, then compress it and FTP it to an entirely different server in a different facility. The net effect is that everything in the repository is not only saved with full history, but that full history is stored in two places. It would take a pair of simultaneous hardware failures to wipe the information out.
So, you've got this near-magical backup happening that is close to zero effort from the client point of view. Encourage people to use it! Set up a portion of the tree for each employee to use for their own stuff (we've got a "Sandbox" subtree, with folders for each user) and tell them to dump into it anything that it would be a nuisance to recreate. Spent an hour tweaking a configuration file for your anti-spam filter? Put it in the sandbox! Working on an article? Sandbox it. Pictures from the office party where the boss put the computer box on his head? Sandbox.
In addition to peace of mind backups (that actually happen without the user needing to remember to do anything) the sandbox is also a great way to move files around from machine to machine. If you need to take a file home from the office, you can just toss it in to the sandbox folder, then connect to the version control server from your laptop or home computer and check it out again.
Depending on your company, this might be the most controversial suggestion - or the most important. If you're using a version control system with a free client, consider setting up a repository with a public face that's visible to anyone on the Internet. Then publicize its existence (and the location of the client software needed to obtain read-only access to it) and start filling it.
Filling it with what? Well, that's up to you. How transparent do you want to be to your customers and partners (knowing, of course, that your competitors will also cruise by to have a look)? Depending on your strategy, this repository might contain:
- Trial versions of your software
- Beta versions of the next release of the software
- Planning documents, from short-term specifications to long-term vision documents
- Company financial statements (if you're a public company)
- Press releases
- Contact information
The goal is simply to make it easy for people to synch up with what you're doing - and what could be easier than moving a portion of your hard drive straight on to their computers?
I mentioned this in a previous article, but it's one of our favorite techniques so I'm going to bring it up again. If your development tree mirrors exactly what you want on your production server (or you can identify a subset of the development tree that should be deployed to the production server), you can use version control for deployment.
To do this, you'll need to install a copy of your version control client on the production server. When your tree is in a known good state and you're ready to deploy, use Remote Desktop to connect to the server and get a copy of the latest version to the server. Voila, instant deployment.
And What Else Can You Do?
I hope these suggestions will get you to thinking about your version control repository as more than just a home for code. Depending on the balance between your daily work and hard drive space, it's quite possible to go even further. For example, have you considered saving your e-mail forever? Or what about the basic development environment that takes you two days to set up? Brainstorm a bit and you're likely to come up with even more creative ideas on your own.
About the Author
Mike Gunderloy is the author of over 20 books and numerous articles on development topics, and the Senior Technology Partner for Adaptive Strategy, a Washington State consulting firm. When he's not writing code, Mike putters in the garden on his farm in eastern Washington state.