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
- 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
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