Elegantly handle site-specific settings/configuration in svn/hg/git/etc ?

Question

I've been looking for a better way to deal with site-specific settings (in this case, the django settings.py file).

The settings.py structure and fields are fairly consistent, but the values differ between the developer's boxes, the integration, QA, testing, and production environments.

What's an elegant way to have the settings source controlled while still allowing changes between different boxes?

I'm also concerned about having sensitive data (eg. database passwords) in source control, but I do want automated deployments.

Examples of what we've used:

• settings.py sets the common values then loads a secondary settings file based on the hostname or the username .

• injecting values into the settings.py file using a deployment script. But this simply shifts the problem to managing the deployment scripts instead of the settings.py script.

Anyone have a particularly elegant approach?

Answer 1

Create a main settings.py file, which should include this:

# Pull in hostname-based changes.
import socket
HOSTNAME = socket.gethostname().lower().split('.')[0].replace('-','')

try:
    exec "from myproject.settings.host_%s import *" % HOSTNAME
except ImportError:
    pass

# Pull in the local changes.
try:
    from myproject.settings.local import *
except ImportError:
    pass

Now you create a new settings file for each host name you care about. But these are really small. Each of your production server's file just contains:

from myproject.settings.production import *

and your staging servers have:

from myproject.settings.staging import *

Now you can create a production.py file with production overrides for settings, a staging.py, and so on. You can make new files for each role a server plays.

Finally, you can create a local.py file on any machine (including developers' machines) with local overrides, and mark this file as ignored by source control, so that changes don't get checked in.

We've used this structure for years, it works really well.

Answer 2

+1 for Ned's answer, but want to mention a slight variation.

I see Django settings as falling into 2 areas: project and instance.

Project settings are common to all the instances (dev, testing, production, multiple sites in production) and instance settings are local to just that specific server instance.

Project settings are things like INSTALLED_APPS (although local settings may also include this to add things like django debug toolbar for developers), MIDDLEWARE_CLASSES, and TEMPLATE_LOADERS. Instance settings are things like the database settings, MEDIA_URL settings, etc.

Project settings go in settings.py and instance settings in local_settings.py, which is imported into settings.py. local_settings.py is listed in .gitignore and project settings are stored in git.

I've tried several other variations on this but ended here because it's just so much simpler.

The only time I don't like this setup is for multiple sites (using Django sites framework), which end up proliferating into things like sitename_settings.py which imports sitename_local_settings.py etc.

Finally, I do keep a local_settings_template.py in git, to use as a starting point for new instances and for devs to track changes they might need to their own local settings.

Answer 3

The way I handle this is to have a base settings.py file and then a settings file for each environment (eg dev_settings.py, live_settings.py)

At the top of each environment specific file I have

from settings import *

I can then simply override any settings I need to change on an environment specific basis

To ensure each environment uses the correct settings I just modify the DJANGO_SETTINGS_MODULE environment variable. How you do this depends how you are deploying django (mod_wsgi, mod_python and so on...)