This is the seventh of ten parts of this blog post. The topics will be:
- 1: A New World
- 2: Architecting JavaScript
- 3: A Better CSS
- 4: Debugging
- 5: Joy and Pain of jQuery Plugins
- 6: Packaging Assets
- 7: Distributed Version Control (this article)
- 8: Working with Facebook
- 9: Mobile Pages
- 10: Deploying to the Cloud (upcoming)
Before I wax poetically about why to use distributed source control, let me talk about what it is (and why it is different).
Back in the very old days (did I mention I am old?) I would keep my source on a floppy disk and put in a safe every night (no, not 9 track tapes like some of you are thinking…I am not *that* old). This was a way to secure the source in case of disaster…but all it did was keep the source secure. Source control was more than that. Later as I used a myriad of source control vendors (yes, including the dreaded Source Safe), they all seemed to have some common features:
- Centralized Storage of Assets
- Management of History
- Handled Consistency of Assets
While I know some companies still don’t use source control of any kind, most do. For many companies they use source control so that they have control of the source. They know where it is and they can back it up and not rely on developers to secure their assets.
In many ways, the key here was that that the source control systems were really version control systems and in fact that is what they became to be called about 10 years into my career. This clarified a real fact, that these were repositories that kept versions of files, not just source code.
The centralization that was the hallmark of those version control systems (VCS) came at a price. The process of pushing changes to the VCS tended to be slow and either relied on locks (check-out, check-in) or handled merging of changes. Since this was a tedious task, developers tended to make big, irregular check-ins as it interrupted their workflow. This is how it was for a long time.
About a decade ago, it became apparent that these VCS systems were also problematic as development teams became more virtual. These VCS systems didn’t handle offsite, or remote situations well…and if they did, they were horrifically slow. For onsite development teams over Ethernet they were fine…but for anything like a distributed team…awful.
Distributed Version Control Systems (DVCS)
Distributed Version Control (or Distributed Source Control if you prefer) is simply a way that turns version control on it’s head. Instead of a single master repository for the source, everyone gets their own repository. This means you can check-in often and really quickly. This encourages developers to make check-ins very granular which makes merging changes from different groups simplier. What happens for the developer is:
- Makes a change.
- Checks in the change to their local repository.
- Eventually bundles a number of these changes to sync with the remote (or master) repository.
Even with small teams, this speeds up development and is just simply cleaner.
But Why?
You may be wondering: “Why is version control part of the Modern Web Development story? Source Safe is working just fine for us.” Ok, I hope that isn’t what you’re thinking…at least the last part.
In building FirstInked, I had to get comfortable with a lot of different ideas. I had used distributed source control before then, but it was purely for open source projects. I had used it to send patches, upload my source to CodePlex (et al). But to use it on a real project with multiple developers, my head was still stuck in the old way.
I knew that I was going to be working with people from wherever was the right place for those people to be. At a coffee shop, in their home town on another continent, wherever. I also knew that I didn’t want to be stuck not being able to do check-ins and keep the granular nature of work even if they (*gasp*) didn’t have an Internet connection. DVCS was what I wanted to be able to get the job done.
In addition, I knew I wanted to be able to do continuous integration so that every sync to the master repository should kick off a build (I’ll talk about how we did that in an upcoming part of this series).
How
There are a handful of DVCS’s out there including GIT, Mercurial (or HG for short) and others. For me I did not want to be the IT department. I wanted to get a company that would simply host our code…privately. They’d do the backups and all would be well. After, very summarily, looking at GIT and Mercurial I took the easy way out and chose Mercurial. My reason? Tooling.
GIT is a great tool (as I am sure many of you will tell me in comments ;) and is mature enough for prime time. It has broad support and a great eco system. But I chose Mercurial because since we were using Visual Studio the tool story for GIT at the time (and mostly the same now) is immature. With GIT there is an expectation that most users will use a BASH shell to submit their changes. The last thing I wanted to do was to was to learn something new. I wanted a tool that would just slip in where I needed it.
So I decided on Mercurial because of the two integration layers I use:
VisualHG is a plugin into Visual Studio that handles add/change/delete/renaming of files in a solution for me. For non-Visual Studio files, I also use TortoiseHG to allow me to add/remove files from the file system (TortoiseHG works as an extension to Explorer).
Hosting
While I could have handled the hosting of Mercurial myself, as I said earlier, I wanted someone to handle that for me. I ended upon BitBucket.org as they changed based on users, not on the #/repositories. I knew that I would probably need a handful of private repositories to fulfill all my projects (WebSite, Mobile Apps, etc.). In fact, BitBucket.org allows up to 5 users with unlimited public *and private* repositories. That means it’s perfect (AFAIAC) for startups.
I don’t use BitBucket.org’s tooling for bug/feature handling or other features. It is simply DVCS hosting for me.
(For the record, I use AgileZen for project management (kanban board) and FogBugz for bug tracking).
What do you think?
