My settings.py file is becoming a mess of if-else statements to handle different database URLs and debug flags. I've seen people use a 'settings' folder with multiple files like base.py and production.py, but I've also heard that environment variables are the "modern" way. Which approach is more scalable for a team of 5 developers using Docker and CI/CD pipelines?
3 answers
We use a settings directory with base.py and local.py. We add local.py to .gitignore so every dev can have their own custom database credentials without breaking the repo.
The best practice in 2024 is a hybrid approach: use a single settings.py file that pulls almost everything from environment variables using a package like 'django-environ' or 'python-dotenv'. This follows the "12-Factor App" methodology. By having one file, you avoid the "where did this setting come from?" headache that occurs with deep inheritance in a settings folder. You can provide a .env.example file for local development and inject the actual production values via your CI/CD secrets manager like GitHub Actions or AWS Secrets Manager.
Do you find that using a single file makes the imports section too cluttered, or does the clarity of seeing all variables in one place outweigh that?
David, the clarity is definitely the winner here. When you use env.db() or env.bool(), the intent is very clear. If a teammate needs to know how the cache is configured, they look in one place. Splitting into base/prod/dev files often leads to "shadowing" where a variable is defined in two places and you accidentally use the wrong one because of the import order. Stick to one file and keep it clean with comments.
I used to do that, Patricia, but I've found that environment variables are much easier to manage once you move into containerized environments like Docker.