Djangocon: slow food digest better (maintain an old project) - Christopher Grebs¶

Tags: djangocon, django, python

(One of my summaries of a talk at the 2018 european djangocon.)

Full title: “slow food digest better - or how to maintain an 8.5 year old python project without getting lost”. Christopher had to maintain such a project - and actually liked it. It was https://addons.mozilla.org, actually.

It started out as a quickly-hacked-together php project. Now it an almost modern django project. The transition from PHP to the django version took almost 16 months. During that time there were bugs, translation errors, downtime: irritating. The site went fully live in january 2010.

The big advantage of the move to django was that lots of tests were added at that time. The site wasn’t anything special. Mostly django. Still quite some raw SQL from the old system. Celery for some tasks.

Mozilla at one time had the “Firefox OS” for mobile phones. For that, they build the “firefox marketplace”. The work was based on the addons.mozilla.org code, but with some weird hacks based on which site it was running… During that time the addons.mozilla.org website itself was pretty much left alone.

In 2015 they had to re-animate the old codebase. At that time it was running django 1.6, barely, as lots of deprecated features were still used as long as they stayed available. The javascript code had almost no unit tests (and the site at the time was javascript-heavy).

So: complete rewrite or incremental improvement? They chose incremental improvement. Rewriting a huge site from scratch for a small team… no. And with the existing system they at least had the advantage of all the existing unittests!

The balance they had to make was between “removing technical dept” and “new features”.

What they did was create a new react-based frontend as a single page app. This got released in december 2017. So they incrementally rewrote the backend (where they had unittests) and did a full rewrite of the frontend (which had no tests).

One thing they used a lot: feature flags/switches. They used “waffle” for that. It makes it much easier to revert broken implementations as you only have to flip a swich back.

Beware of third party dependencies. They can be a great pain. Especially when you want to upgrade your django version. On the frontend you have a similar problem: there you can be inundated by javascript versions and updates and problems. Make sure your dependencies are up-to-date and maintained. If not, fix it or move to other libraries.

They steered their django upgrades with waffle feature flags. Once the new django version was fully in production, they could remove the feature flags for the old version.

A quality assurance safes lives. Unittests are good, but a real QA team that really tests it discovers lots of problems. And purely the fact that you need to explain the upgrade process to the QA engineers already helps.

And… don’t panic. You’re there for the long run. Great food needs time, why should your software be different?

Photo explanation: constructing a viaduct module (which spans a 2m staircase) for my model railway on my attic.