[Fab-user] Re: Specify what directory should be rsynced

[Wes Winham]

For my particular case, I started out using a bzr lightweight check
and bzr up to do those updates, just as you would expect. There were a
few issues that eventually convinced me that was not the best for my
case:
 1. We keep selenium tests, xml representation of manual acceptance
tests, a customized selenium instance, some development-only django
apps and some ec2_api tools in our repository, but don't want to put
those on our remote deployments (those things together take up more
space than the rest of the code base put together) and I didn't find a
good way to keep from transferring all of those over the network. I
could delete them afterwards, obviously, but considering that network
transfer is about 2/3rds of the latency in a deployment update for us,
it's a large amount of overhead. When I use fab to tar and push, I can
exclude the stuff I don't want on an actual deployment.
2. Our deployment is decentralized for the most part so that I might
want to be deploying out of completely different bzr branches
throughout the day as I switch around and other developers will do the
same. That's mostly an issue for deploying to testing/staging
instances since our live instances have their own bzr branch
(basically for the same purpose you do a tag in SVN) and we could
count on them staying consistent. We could switch where the bzr branch
was bound on the server, but we keep our deployment idempotent and
it's much more difficult to satisfy that condition if you might be
switching checkouts, might be creating a checkout or might just be
sticking with the same branch.
3. We run deployments mostly from developer machines and relying
solely on our version control system forced us to push any local
changes to our dev server (where we keep centralizedish backups of our
branches) before deploying any changes since a given developer machine
probably doesn' t have a publicly addressable IP address that the ec2
instance can use to grab the code.

I find it very useful to deploy to an ec2_instance to test some
changes multiple times per day while switching between bzr feature
branches and fabric with tarring + push has made that experience super
awesome.

I hope that makes sense.
-Wes

On Thu, Apr 16, 2009 at 11:00 AM, Jeff Forcier <address@hidden> wrote:
> On Thu, Apr 16, 2009 at 10:52 AM, Wes Winham <address@hidden> wrote:
>> I'm super excited about how much rsync is going to speed up my
>> deployment process when I'm just applying small changes. Thanks for
>> the awesome work.
>
> Call me silly, but isn't this what version control is for? Maintain a
> checkout of your release branch (or a release tag) and then just do
> e.g. "svn up" (or "svn switch") during your deploy process.
>
> I'm sure there are plenty of scenarios where that doesn't work, but
> for the common case it seems to be widespread enough to be considered
> best practices *shrug*
>
> At any rate, I'm definitely all for adding flexibility to the builtin
> tools like rsync_project -- so don't think I'm poo-pooing that! --
> just curious what it may offer over what I'm personally used to.
>
> Best,
> Jeff
>
> P.S. Still cranking away on magic-removal, been relatively busy lately
> but hoping to get back on it full-steam soon!
>