Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Deploying Django sites with Fabric, Pip and virtualenv: Ryan Williams (ryanwilliams.org)
52 points by Goosey on March 29, 2010 | hide | past | favorite | 12 comments


Note that this article is almost a year old, and the fabfile.py example he has here is using the old version of Fabric.

There's been a pretty significant overhaul of Fabric since then, and it's really improved quite a bit. You can check out the major changes in current release here: http://docs.fabfile.org/0.9.0/changes/0.9.html


kraftwerk is the evolved way to do this. http://www.kraftwerk-wsgi.com/

I am the author. Check it out and tell me what you think!


Looks somewhat similar to Ian Bicking's Silver Lining (née Toppcloud): http://cloudsilverlining.org/


Yes kraftwerk came after Silver Lining and even uses some of its code.


kraftwerk seems to have a different use-case than fabric. There is some overlap, but they are different tools for different jobs.

Of course this article pretty much hits the overlap right on the head...


True. kraftwerk is a deployment tool (Python WSGI only) and Fabric is more general although it leans towards deployment automation.


Shameless plug ahead

I may need to write up something on the subject, but you can use envbuilder[1] to simplify working with the pip and virtualenv part. This works especially well if you have several chunks of code you need to check out from VCS.

[1] http://github.com/jasonbaker/envbuilder


Nice writeup. I use something similar for my Django deployments.

Although I still don't like the way you have to write commands in fabric. I mean, the multiple commands in the single run call. Its not quite readable and thus too error prone.


But the beauty of commands being implemented via python code is you can extended it arbitrarily. One of the first things I did with fabric is write some additional code that would optionally dump a shell script instead of running all the commands so I could more easily debug it/see what's going to happen.


What's the purpose of the timestamped versions? (As opposed to just one version, or just running it from the .git checkout?)


It's much easier to rollback if something goes wrong. You have a "known" good copy and just change a symlink.

We do the timestamped versions too, but our build process tars everything we need up and SCPs it over. Our release directories usually need to be transformed, though, and can't work as a simple git checkout.


OT: Animated favicons: Just Say No. (Yes, I'm sure there's a way to disable it client-side but the point remains.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: