The Problem with Git in Rapid-fire Webapp Development

Posted on December 11, 2007

Git has been getting a lot of coverage these days.

The technology behind git sounds nothing less than spectacular. But how does git improve day-to-day productivity in this kind of environment?

Time it takes to perform/think about “version control” (in this case, Subversion) in parenthesis.

  • Do some hacking for maybe 2 hours. Make a checkin. (15 seconds)
  • Svn update on server. (15 seconds)
  • Oops, wasn’t 100% right or need to make a quick fix. Check that in. (10 seconds)
  • Update production. (10 seconds)

...

Git sounds wonderful if you need to do a lot of intricate braching.

For my development style, that just isn’t the case. I’m also not ashamed to admit that I find Capistrano highly overrated when it comes to managing deployments.

Don’t get me wrong—it’s an excellent tool if you want to add that much overhead to your deployment process, ability to rollback, etc, etc.

Here’s where it failed me:

  • in one intricate app, while deploying, there were always several ancillary processes going on in the background. Capistrano would always hang for 5-10 minutes while trying to stop these.
  • checkout of the core code takes 5+ minutes (slow remote svn repo or biiig rails apps)—who wants to sit around for 5 minutes when an incremental ‘svn up’ takes 15 seconds?
So—yes, that’s how I “deploy” my Rails applications, and have never had a problem yet. Here is the simple 30 second workflow:
cd /u/apps/foo/current
svn up .
mongrel_rails cluster::stop
# manually make sure all mongrels have stopped, and possibly: rm -rf log/*
mongrel_rails cluster::start

And PZZaaaaaaaam—I’m deployed.

So adding things like git and capistrano would simply slow me down. If you’re deployment cycle takes 1-2 days (for full UI testing, etc—ugh) then by all means, use capistrano, git, whatever. But for the “ultra agile” style, these fancy techniques are overkill, IMHO.