Continuous integration and continuous deployment - Szilveszter Farkas (djangocon.eu)¶

Tags: djangocon, django

Szilveszter works for http://prezi.com/, an online presentation website.

For their site, they had a small test suite. 30% coverage. Everyone had feature branches. When completed they were merged and released, leading to bugs and integration issues. Now they use continuous integration and continuous deployment and their process is much more slick.

Branching for feature branches often used to end up in a “merge hell”. What they, ironically, do is to use a centralized model now. Everyone works on trunk/master and every commit is emailed and can be reviewed. Features are written concurrently in that same trunk/master.

They fixed their test coverage by fixing all failing tests first. Then the rule was instated that every new piece of code must have tests. And bugs need a test too.

For continuous integration they use jenkins. For django, there’s integration with django-jenkins.

The continuous integration is not to the production system, but to a staging system. That really helps quality assurance, as there’s always a fresh website to work with.

But… how do you release features that take more than a day to implement? Well, just release them every day, but don’t show them to (all) users. They use gargoyle to flag features to manage which users can see which bits of new functionality. They can incrementally roll out new features to users this way.

Future wishlist:

• Dashboard.

• One-click deploy.

• Sentry as an error reporting tool.