我使用settings_local.py和settings_production.py。在尝试了几个选项后，我发现当简单地拥有两个设置文件时，很容易在复杂的解决方案上浪费时间。

当你在Django项目中使用mod_python/mod_wsgi时，你需要将它指向你的设置文件。如果你把它指向本地服务器上的app/settings_local.py和生产服务器上的app/settings_production.py，那么事情就变得简单了。只需编辑适当的设置文件并重新启动服务器(Django开发服务器将自动重新启动)。

在settings.py:

try:
    from local_settings import *
except ImportError as e:
    pass

你可以覆盖local_settings.py;它应该不在你的版本控制范围之内。但既然你提到了复制，我猜你没有使用;)

1 -在你的应用程序中创建一个新文件夹，并设置它的名称。

2 -现在在其中创建一个新的__init__.py文件，并在其中写入

from .base import *

try:
    from .local import *
except:
    pass

try:
    from .production import *
except:
    pass

3 -在设置文件夹local.py和production.py和base.py中创建三个新文件。

4 -在base.py中，复制之前settings.py文件夹中的所有内容，并将其重命名为old_settings.py。

5 -在base.py中更改BASE_DIR路径以指向新的设置路径

旧的路径- > BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

新建路径-> BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

通过这种方式，项目总监可以结构化，并且可以在生产和本地开发之间进行管理。

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

大多数解决方案的问题是，您要么将本地设置应用在常用设置之前，要么应用在常用设置之后。

所以不可能覆盖

特定于env的设置定义了memcached池的地址，在主设置文件中，这个值用于配置缓存后端 特定环境的设置添加或删除应用程序/中间件到默认的

同时。

一种解决方案可以使用“ini”风格的配置文件和ConfigParser类实现。它支持多个文件、延迟字符串插值、默认值和许多其他优点。 一旦加载了许多文件，就可以加载更多的文件，它们的值将覆盖之前的文件(如果有的话)。

您可以加载一个或多个配置文件，这取决于计算机地址、环境变量，甚至是先前加载的配置文件中的值。然后只需使用解析后的值填充设置。

我成功使用的一个策略是:

Load a default defaults.ini file Check the machine name, and load all files which matched the reversed FQDN, from the shortest match to the longest match (so, I loaded net.ini, then net.domain.ini, then net.domain.webserver01.ini, each one possibly overriding values of the previous). This account also for developers' machines, so each one could set up its preferred database driver, etc. for local development Check if there is a "cluster name" declared, and in that case load cluster.cluster_name.ini, which can define things like database and cache IPs

举个例子，你可以定义一个“子域”值per-env，然后在默认设置中使用(hostname: %(subdomain).whatever.net)来定义django工作所需的所有必要的主机名和cookie。

这是我能得到的DRY，大多数(现有的)文件只有3或4个设置。除此之外，我还必须管理客户配置，所以存在一组额外的配置文件(包括数据库名称、用户和密码、分配的子域等)，每个客户一个或多个。

您可以根据需要将其扩展到低或高，只需在配置文件中放入您想要在每个环境中配置的键，一旦需要新的配置，将先前的值放在默认配置中，并在必要时覆盖它。

该系统已被证明是可靠的，并与版本控制工作良好。它已经被使用很长时间来管理两个独立的应用程序集群(每台机器上有15个或更多的django站点实例)，有超过50个客户，集群的大小和成员会根据系统管理员的情绪而变化……

记住，settings.py是一个活动代码文件。假设您没有在生产中设置DEBUG(这是一个最佳实践)，您可以执行如下操作:

if DEBUG:
    STATIC_PATH = /path/to/dev/files
else:
    STATIC_PATH = /path/to/production/files

非常基本，但是理论上，您可以根据DEBUG的值或您想使用的任何其他变量或代码检查来提高任何复杂级别。