Wellfire Interactive // Expertise for established Django SaaS applications
Does your Django site schedule maintenance for you? (This Old Pony #63)
I’ve been thinking about this sign the past few days.
Maybe it’s a sub conscious reminder to tend to the snow thrower before winter hits.
It’s a charmingly folksy sign and its one that I think most of us can relate to. We get the oil in our cars changed before it burns or turns to sludge; we re-roof our houses before water starts leaking, and we floss our teeth before gingivitis attacks our mouths (sorry for that image).
Each of those activities is predicated on at least one concrete negative outcome in a physical system. Even for the non-mechanical, the less-than-handy, and the not-so-keen-on-poking-our-gums the preventative value and causal path for maintenance is clear, as are the consequences. Less so for software.
What constitutes Django site maintenance?
The first and likely most obvious component of maintenance for a Django site is Django version upkeep, that is, keeping current with the latest supported version of Django or at least the latest bug fix/security fix version of the version you’re using (i.e. a long term support version).
The next extends this to the site’s related dependencies. Beyond Django itself most site’s include numerous third-party apps which may have their own version updates in support of new Django versions or fixing various bugs and/or security issues.
Creating and validating backups is likewise important. Typically this consists of verifying that scheduled backups are running and then periodically testing the backups by restoring a database successfully from a backup file, rather like checking the tire pressure on a spare tire.
More generally there are various third-party HTTP-based tools you might use to periodically test the site, from security to uptime to spelling.
If this is a site with significant active development you’d also include a number of tasks related to performance tracking, refactoring, etc.
Why replace the roof when it’s sunny?
Or more aptly, why do any of this? What is the tangible benefit, and what’s the cost? And, sheesh, how can software possibly degrade like a roof?
The answer, of course, is that software doesn’t degrade like a roof. It’s more like a piece of mechanical equipment with lots of interesting mechanical interfaces in a world where the tooling to work on the machine goes away at a comparatively stupendous rate and likewise the ways in which the machine may be gummed up or attacked multiplies by the month.
Physical systems are a bad metaphor for this reason, because even the most dynamic are static by comparison. The risk with a Django site is not that some URL will suddenly disappear or that the HTML templates will begin rotting (although it’s totally possible for damage at the disk level to make it seem so!).
No, the risk is that the universe of supporting software will migrate past your application, that a minor update will become an unexpected major overhaul, or that a disk failure results in a otherwise avoidable data loss.
Solving for maintenance
Typically the most critical part of maintaining a web application - after ensuring the codebase is version controlled, that is - is establishing an automated database backup schedule and verification process. The entire process can be automated, although in most cases it will suffice to automate the backups and set up a manual process for testing backups (this depends heavily on the nature of the application).
There are various services that will monitor your dependencies to alert you when one or more are known to have security vulnerabilities or have simply been surpassed by newer versions. Getting a good view of this might be made easier by adopting Pipenv[0] but this depends on service support. Likewise, you can periodically run security scans on against your site to verify that it isn’t susceptible to certain types of attacks.
When it comes to the application itself, it helps to have automated systems in place. This includes deployment, testing, and development environment setup. The former two can also be run by a separate system - a continuous integration system - to ensure that every change is tested and deployed only with the right previously decided criteria passing.
Most apps built in real world situations will have room for improvement, whether that’s customer visible performance or developer visible code fixups. These can’t always be addressed all at once, so plan to keep a wishlist for improvement which can be prioritized and nibbled off week by week, month by month, or quarter by quarter. Small improvements add up, but only when executed.
Repairingly yours,
Ben
[0] Pipenv is kind of like if you combined a Gemfile (used by Ruby’s “gem” tool) with virtualenv path management built in https://pipenv.readthedocs.io/en/latest/
Learn from more articles like this how to make the most out of your existing Django site.