A common paradigm in Django is to create different settings files for different environments (local, production, staging, etc.). Everyone has their own opinion on how to set these up (see ours here), that’s not what this post is about. Instead, I’d like to point out the inherent danger in this technique and how to prevent shooting yourself in the foot.
When setting up an environment-specific settings file, each setting should be looked at as an untestable point-of-failure. Have you ever found yourself saying, “…but it worked fine on {staging, my machine, etc.}”? This is a problem of parity and it starts with your settings files. Just because you can change all your settings between environments, it doesn’t mean you should. Use restraint. Make your settings as close as possible between environments and examine every divergence to make sure it is absolutely necessary (inheriting from a common base settings file makes the comparison easy). Here’s a few things that you’ll likely need to change between your environments:
- database connection details
SECRET_KEY- 3rd party API keys
If your settings switches only contain those types values, then pat yourself on the back. If, on the other hand, they vary on things like:
- installed apps
- database engines
- middleware
DEBUG
…you’re asking for trouble. It’s ok to adjust these for local debugging, but they should never hit a dev or staging server.
Aim for parity in your settings and you’ll save yourself some heartache and head-scratching down the road.
