Getting to Continuous Deployment in Django: Feature Flipping with Gargoyle and Django Waffle

this post is a first in a series of posts about our move towards continuous deployment using django.

continuous deployment is a process by which code that is written for an application is constantly deployed into production without manual intervention. this allows us to be agile, to quickly innovate, and more importantly, to bounce back from any grave errors, unscathed.

when it comes to building new features, this can involve merging feature branches, rigorous code review, testing, and deployments, before you can test it out on a live environment. every subsequent release to different groups of users would require code changes, and deployment.

this can be avoided by employing feature flipping , which is an essential step towards achieving continuous deployment in your application.

so what is this feature flipping thing, anyway?

in its most basic form, you can think of it as applying an on/off switch to a piece of code in your codebase thereby releasing or rolling back a feature.

this allows you to constantly push new code for features that you’re not quite ready to release to any of your users yet. and when you’re ready, you can do a gradual rollout of the feature - to various groups of users. all, from a simple dashboard, with a single click.

analysis of django feature flipping libraries

there are a number of open source libraries in django that can be used for this purpose. recently, we analyzed our various options - the two biggest contenders were gargoyle and django waffle . following is the result of our evaluation:

ease of installation:

both libraries can be installed via pip or easy install and have to be included in your list of installed_apps. waffle also requires you to add a middleware and a context_processor for templates.

switches and flags:

both libraries support applying a switch to a piece of code via a conditional, a decorator to a view or template tags in django.

gargoyle, however, allows you to set conditions to your switches such as percentage of users, groups or specific users. it also allows us to associate percentages with users ip address - release it to 30% of ny, 10% of chicago etc.

waffle takes a different approach to this and uses flags, which when activated can be applied to groups, specific users, or a set percentage of users. although flags can be triggered in every way that a switch can be, they are tied to request objects while switches are named booleans in the database. the flipping uses cookies and is session based so ‘smart’ users can get around it but this can be avoided by adding a user to a group when they initially encounter the feature, and enabling the feature for that group.

usage in javascript:

waffle allows us to use switches and flags in javascript by including the appropriate js file and using the global waffle object.

if (waffle.flag('some_flag')) {
   // flag is active.
} else {
   // flag is inactive.
}`
`
if (waffle.switch('some_switch')) {
   // switch is active.
} else {
   // switch is inactive.
}

gargoyle does not currently support javascript.

admin frontend:

although not necessary, gargoyle encourages the use of nexus for the django admin frontend. if you choose not to do this however, you will need to enable the discovery of gargoyle.py modules in your urls.py.

import gargoyle
gargoyle.autodiscover()`

final thoughts

as mentioned earlier, both libraries are strong contenders in the django feature flipping community and can be easily forked on github to add extra functionality if required, instead of reinventing the wheel.

finally, while feature flipping definitely has its upsides it can have its disadvantages. although this means less merges, continuous integration and frequent and smaller deployments, constant maintenance of the codebase is necessary once a feature is completely released so you don’t have to maintain multiple versions.

nitya oberoi is a developer at yipit.