Primary image for Simple & Easy Deployment with Fabric and Virtualenv

Simple & Easy Deployment with Fabric and Virtualenv

In the process of prepping Gondola CMS for public consumption, we’ve grown from having a developer (me), to having a development team. One pain point that quickly arose was the amount of time it took for new developers to setup a local development environment. In addition to our source code, the project depends on nearly a dozen other Django apps and Python packages. Initially, we simply tracked the requirements in a text file, but it required a lot of manual work to get them downloaded and installed.

Necessity is the Mother of Invention

Of course, this problem has been tackled many, many times before1. As I looked into what was out there, my first thought was that most of the existing options were far too complex for our needs. If I didn’t grok a system after clicking around the docs for 10 minutes or so, I moved on. The tool I eventually decided on was Fabric.

I was attracted to Fabric, primarily because I found it simple and easy to understand. Unfortunately, I didn’t find a lot of information on using it for local buildouts, so I forged ahead building my own.

fab bootstrap

Our needs were simple. I wanted a script that would:

  1. Setup our standard directory structure
  2. Download source code from a number of disparate systems, properly handling branches and version requirements
  3. Load the source into a virtualenv

The results of a few hours of hacking are available as lincoln-loop-deploy. Our local buildout is now a simple process:

  1. Get requirements: easy_install Fabric virtualenv
  2. Checkout our buildout repository (only contains 2 files fabfile.py and fabreqs.py)
  3. Build project: fab bootstrap
  4. Activate the virtualenv: source ./ve/bin/activate

My goal is to keep the fabfile.py totally generic so it can be used across all our projects. While it serves my purposes for now, we’ll likely be extending it in the future to allow for remote deployment, source updates, and additional version control systems. Yann and I also discussed an option to work without the virtualenv requirement for those who haven’t seen the light yet don’t want to use it.

Do you have a better way of doing things? We’d love to hear what you have to say. Patches are always welcome too.

1 Ian Bicking’s summary of build systems

Peter Baumgartner

About the author

Peter Baumgartner

Peter is the founder of Lincoln Loop, having built it up from a small freelance operation in 2007 to what it is today. He is constantly learning and is well-versed in many technical disciplines including devops, …

View Peter's profile