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

创建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。

我使用了上面提到的jpartogi的一个变体，我觉得它更简短:

import platform
from django.core.management import execute_manager 

computername = platform.node()

try:
  settings = __import__(computername + '_settings')
except ImportError: 
  import sys
  sys.stderr.write("Error: Can't find the file '%r_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" % (computername, __file__))
  sys.exit(1)

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

基本上，在每台计算机(开发或生产)上，我都有适当的动态加载的hostname_settings.py文件。

我将我的设置拆分如下

settings/
     |
     |- base.py
     |- dev.py
     |- prod.py  

我们有三种环境

dev 暂存 生产

现在，显然登台和生产应该有尽可能相似的环境。所以我们同时保留了prod.py。

但是在这种情况下，我必须确定正在运行的服务器是生产服务器。@T。斯通的回答帮助我写了如下支票。

from socket import gethostname, gethostbyname  
PROD_HOSTS = ["webserver1", "webserver2"]

DEBUG = False
ALLOWED_HOSTS = [gethostname(), gethostbyname(gethostname()),]


if any(host in PROD_HOSTS for host in ALLOWED_HOSTS):
    SESSION_COOKIE_SECURE = True
    CSRF_COOKIE_SECURE = True  

我发现这里的回答很有帮助。(这个问题是否得到了更明确的解决?上一次回复是在一年前。)在考虑了列出的所有方法之后，我提出了一个在这里没有列出的解决方案。

我的标准是:

所有东西都应该在源代码控制中。我不喜欢精细的东西到处乱放。 理想情况下，将设置保存在一个文件中。如果我不看东西，我就会忘记它们:) 无需部署手动编辑。应该能够用一个fabric命令测试/推送/部署。 避免将开发设置泄漏到生产环境中。 让Django布局尽可能接近“标准”(*咳嗽*)。

我认为打开主机是有意义的，但后来发现真正的问题是针对不同环境的不同设置，并有了一个顿悟时刻。我把这段代码放在settings.py文件的末尾:

try:
    os.environ['DJANGO_DEVELOPMENT_SERVER'] # throws error if unset
    DEBUG = True
    TEMPLATE_DEBUG = True
    # This is naive but possible. Could also redeclare full app set to control ordering. 
    # Note that it requires a list rather than the generated tuple.
    INSTALLED_APPS.extend([
        'debug_toolbar',
        'django_nose',
    ])
    # Production database settings, alternate static/media paths, etc...
except KeyError: 
    print 'DJANGO_DEVELOPMENT_SERVER environment var not set; using production settings'

这样，应用程序默认为产品设置，这意味着你明确地将你的开发环境“白名单”。忘记在本地设置环境变量要比反过来忘记在生产环境中设置一些内容而使用一些开发设置安全得多。

在本地开发时，无论是在shell中，还是在.bash_profile中，或者其他任何地方:

$ export DJANGO_DEVELOPMENT_SERVER=yep

(或者如果你在Windows上开发，可以通过控制面板或者其他什么工具来设置…Windows总是让它变得如此模糊，以至于你可以设置环境变量。)

使用这种方法，开发设置都在一个(标准)位置，只需在需要的地方覆盖生产设置。任何与开发设置有关的事情都应该完全安全地提交到源代码控制中，而不会对生产产生影响。

我使用Harper Shelby发布的“if DEBUG”风格设置的稍微修改版本。显然，根据环境(win/linux/等等)，代码可能需要稍作调整。

我在过去使用“if DEBUG”，但我发现偶尔我需要用DEUBG设置为False进行测试。我真正想要区分的是环境是生产环境还是开发环境，这给了我选择DEBUG级别的自由。

PRODUCTION_SERVERS = ['WEBSERVER1','WEBSERVER2',]
if os.environ['COMPUTERNAME'] in PRODUCTION_SERVERS:
    PRODUCTION = True
else:
    PRODUCTION = False

DEBUG = not PRODUCTION
TEMPLATE_DEBUG = DEBUG

# ...

if PRODUCTION:
    DATABASE_HOST = '192.168.1.1'
else:
    DATABASE_HOST = 'localhost'

我仍然认为这种设置方式是一种正在进行中的工作。我还没有看到任何一种方法来处理Django设置，它涵盖了所有的基础，同时设置起来也不是很麻烦(我不喜欢5x设置文件方法)。