For a long time I was content with the SSH into the server and do stuff
approach to deployment (I'm not managing any large deployments, and am
usually dealing with small projects without the resources for staging
servers and such), but I've been intoxicated by Fabric's sweet poison, and I think it's a
noticable improvement--even for the smallest of deployments.

Briefly, I think using Fabric (or something similar) is a real win
because:

You never have to leave your system. You get to use your tools,
your files, your setup.

You only have to type one command to perform the deployment.
Even for simple deployments you're still typing one or two
dozen shell commands (changing directories, pulling from version
control, rebooting the server), and you just don't have to type
those commands anymore.

Even if that seems like a small gain, I think it's more than
that, because you can actually deploy without breaking your
programming flow.

With a good deployment solution, you type once and then run it many times, so you're more
likely to do things the right way instead of the quick way.
(Repetition leads to boredom, boredom to horrifying mistakes, horrifying mistakes to God-I-wish-I-was-still-bored, and
it goes downhill from there.)

Other developers, even those who wake up with a cold sweat when
dreaming about linux administration, can deploy and rollback as
well. If you throw a five minute GUI on top, then even your
grandmother can be out there deploying and rolling back your
production servers.

By abstracting the deployment process into a simple deployment
script you're making it easiser for other people to do your
job for you. Which is a good thing. Unless you're worried that
you seem unproductive at work. Then you might not like Fabric.

It scales well to large environments.

Now let's take a brief stroll through my Fabric setup.

Using Fabric

You can install Fabric using easy_install, but I'm using
the current Git checkout, and the project is still young enough
that code written for the latest packaged release will not work
for the current development head1. So I recommend you install it
from its Git repository.

Fabric's approach makes it easier to
pass state around between various commands.
Well, that's their story anyway. I'm not
going to defend the approach beyond saying
that I suspect they're working around some
pain point in their architecture.

Now that we have those Git utilities, lets fill
in the rest of the fabfile.py so that it can
take advantage of the utilities.

The first thing you should do is create one or more
functions, one for each set of servers you want to
handle in a different way. For example, if you
have a cluster of production servers and a cluster
of staging servers, then you'd write something
like this:

The fab_hosts value is a special value that Fabric uses
to determine the servers to run commands on, but the repos
value is something that I added in myself for my scripts.
You can add as many arbitrary values to config as your heart desires.

Now to put together the three functions I use for managing
deployment.