Continuous Integration with Tarmac and Vagrant

As part of our self-improvement and knowledge sharing within Canonical, within our group (Professional and Engineering Services) we regularly – at least once a month – run what we call an “InfoSession”. Basically it is Google Hangout on Air with a single presenter on a topic that is of interest/relevance to others, and one of my responsibilities is organising them. Previously we have had sessions on:

  • Go (a couple of sessions in fact)
  • SystemTap
  • Localization (l10n) and internationalization (i18n)
  • Juju
  • Graphviz
  • …and many others…

Today the session was on continuous integration with Tarmac and Vagrant, presented by Daniel Manrique from our certification team. In his own words:

Merge requests and code reviews are a fact of life in Canonical. Most projects start by manually merging approved requests, including running a test suite prior to merging.

This infosession will talk about tools that automate this workflow (Tarmac), while leveraging your project’s test suite to ensure quality, and virtual machines (using Vagrant) to provide multi-release, repeatable testing.

Like most of our sessions it is publicly available, here it is is for your viewing pleasure:

Tempus fugit

Nine years, one month.

That’s how long I’ve had one server running with Linode. It has been through a number of versions of Ubuntu, and been re-installed at least twice (once to switch from 32-bit to 64-bit). It has operated as a LugRadio mirror; hosted many websites, both static and dynamic; hosted my blog for many years; operated as a Jenkins server; and done more general duties as an IRC bouncer, and general dogsbody.

Why the sentimentality? I’m shutting the server down today. Not that anyone will notice of course (unless you’re paying close attention to IP addresses or SSH host keys) since it has already been replaced with a DigitalOcean droplet (still running Ubuntu of course).

Linode have done absolutely nothing wrong – in fact just the opposite. I have been regularly rewarded with extra storage/memory/bandwidth, and they have always been responsive to my few needs. So much so that I am still remaining a customer. (So far) I am only moving one server to DigitalOcean.

So why the change? A few reasons: that server now does very little besides running my IRC bouncer; I wanted to try DigitalOcean out (I have heard a lot of good things); finally, perhaps most importantly considering the first reason – the droplet is half the price of the linode. In fact if I had gone for the $5 per month droplet instead of the $10 one, I could have had four servers for the price of one!

django-getenv – use environment variables in your Django settings

So I made a thing for using environment variables within your Django settings: django-getenv.

Although the code itself is trivial (and, to be honest, not coupled with Django in any way), because I was re-using the same code in multiple projects I decided – if only to make my life easier – to made it into a standalone module and package.

Enough of the what, let us get onto the why.

I’m a big fan of The Twelve-Factor App, and although I can’t or don’t always follow its tenets in every app I write, I do my best.

One of the tenets is “Store config in the environment”:

The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.

Although Django has a range of configuration options, it does not lend itself well to using environment variables out of the box.

Jacob Kaplan-Moss has addressed part of this with django-dotenv which lets you use a Foreman-style .env file to populate your environment with the settings contained within that file.

django-getenv is another piece of the puzzle, helping you use those environment variables in your Django project settings. As well as simplifying accessing these variables, it will also convert boolean, integer and float values to their native Python types.

The module is BSD (3-clause) licensed, available on Pypi, and the project is hosted on Github.