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 <[email protected]> wrote: > On Thu, Apr 16, 2009 at 10:52 AM, Wes Winham <[email protected]> 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! > _______________________________________________ Fab-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fab-user
