对于我的大多数项目，我使用以下模式:

创建settings_base.py，其中存储所有环境的通用设置 每当我需要使用具有特定要求的新环境时，我都会创建新的设置文件(例如。Settings_local.py)，它继承settings_base.py的内容，并覆盖/添加适当的设置变量(从settings_base import *)

(要使用自定义设置文件运行manage.py，只需使用——settings命令option: manage.py <命令>——settings=settings_you_wish_to_use.py)

创建多个版本的settings.py是12因素应用程序方法论的反模式。 请使用python- decoupling或django-environ。

我在manage.py中区分它，并创建了两个单独的设置文件:local_settings.py和prod_settings.py。

在manage.py中检查服务器是本地服务器还是生产服务器。如果它是本地服务器，它将加载local_settings.py，如果它是生产服务器，它将加载prod_settings.py。基本上是这样的:

#!/usr/bin/env python
import sys
import socket
from django.core.management import execute_manager 

ipaddress = socket.gethostbyname( socket.gethostname() )
if ipaddress == '127.0.0.1':
    try:
        import local_settings # Assumed to be in the same directory.
        settings = local_settings
    except ImportError:
        import sys
        sys.stderr.write("Error: Can't find the file 'local_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file local_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
        sys.exit(1)
else:
    try:
        import prod_settings # Assumed to be in the same directory.
        settings = prod_settings    
    except ImportError:
        import sys
        sys.stderr.write("Error: Can't find the file 'prod_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file prod_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
        sys.exit(1)

if __name__ == "__main__":
    execute_manager(settings)

我发现将设置文件分开到两个单独的文件中更容易，而不是在设置文件中做大量的if。

对于我的大多数项目，我使用以下模式:

创建settings_base.py，其中存储所有环境的通用设置 每当我需要使用具有特定要求的新环境时，我都会创建新的设置文件(例如。Settings_local.py)，它继承settings_base.py的内容，并覆盖/添加适当的设置变量(从settings_base import *)

(要使用自定义设置文件运行manage.py，只需使用——settings命令option: manage.py <命令>——settings=settings_you_wish_to_use.py)

Django 1.5的最佳实践建议对你的设置文件使用版本控制，并将文件存储在一个单独的目录中:

project/
    app1/
    app2/
    project/
        __init__.py
        settings/
            __init__.py
            base.py
            local.py
            production.py
    manage.py

base.py文件包含常见设置(如MEDIA_ROOT或ADMIN)，而local.py和production.py有特定于站点的设置:

在基本文件设置/base.py:

INSTALLED_APPS = (
    # common apps...
)

在本地开发设置文件settings/local.py中:

from project.settings.base import *

DEBUG = True
INSTALLED_APPS += (
    'debug_toolbar', # and other apps for local development
)

在文件生产设置文件设置/production.py:

from project.settings.base import *

DEBUG = False
INSTALLED_APPS += (
    # other apps for production site
)

然后当你运行django时，你添加——settings选项:

# Running django for local development
$ ./manage.py runserver 0:8000 --settings=project.settings.local

# Running django shell on the production site
$ ./manage.py shell --settings=project.settings.production

这本书的作者还在Github上发布了一个示例项目布局模板。

不要使用settings.py，而是使用下面的布局:

.
└── settings/
    ├── __init__.py  <= not versioned
    ├── common.py
    ├── dev.py
    └── prod.py

py是您的大部分配置所在的位置。

py从common中导入所有内容，并覆盖它需要覆盖的内容:

from __future__ import absolute_import # optional, but I like it
from .common import *

# Production overrides
DEBUG = False
#...

类似地，dev.py从common.py导入所有内容，并覆盖它需要覆盖的内容。

最后，__init__.py是你决定加载哪些设置的地方，也是你存储秘密的地方(因此这个文件不应该被版本化):

from __future__ import absolute_import
from .prod import *  # or .dev if you want dev

##### DJANGO SECRETS
SECRET_KEY = '(3gd6shenud@&57...'
DATABASES['default']['PASSWORD'] = 'f9kGH...'

##### OTHER SECRETS
AWS_SECRET_ACCESS_KEY = "h50fH..."

我喜欢这个解决方案的原因是:

所有东西都在您的版本控制系统中，除了机密信息 大多数配置都在一个地方:common.py。 特定于产品的东西放在prod。py中，特定于开发的东西放在dev。py中。这很简单。 你可以在prod.py或dev.py中覆盖common.py中的内容，也可以覆盖__init__.py中的任何内容。 这是简单的python。没有重新导入黑客。