为本地开发和生产服务器处理设置的推荐方法是什么?其中一些(如常量等)可以在两者中更改/访问,但其中一些(如静态文件的路径)需要保持不同,因此不应该在每次部署新代码时都重写。
目前,我正在将所有常量添加到settings.py中。但是每次我在本地更改一些常量时,我都必须将其复制到生产服务器并编辑文件以进行特定于生产的更改……:(
编辑:看起来这个问题没有标准答案,我已经接受了最流行的方法。
为本地开发和生产服务器处理设置的推荐方法是什么?其中一些(如常量等)可以在两者中更改/访问,但其中一些(如静态文件的路径)需要保持不同,因此不应该在每次部署新代码时都重写。
目前,我正在将所有常量添加到settings.py中。但是每次我在本地更改一些常量时,我都必须将其复制到生产服务器并编辑文件以进行特定于生产的更改……:(
编辑:看起来这个问题没有标准答案,我已经接受了最流行的方法。
当前回答
在settings.py:
try:
from local_settings import *
except ImportError as e:
pass
你可以覆盖local_settings.py;它应该不在你的版本控制范围之内。但既然你提到了复制,我猜你没有使用;)
其他回答
记住,settings.py是一个活动代码文件。假设您没有在生产中设置DEBUG(这是一个最佳实践),您可以执行如下操作:
if DEBUG:
STATIC_PATH = /path/to/dev/files
else:
STATIC_PATH = /path/to/production/files
非常基本,但是理论上,您可以根据DEBUG的值或您想使用的任何其他变量或代码检查来提高任何复杂级别。
对于我的大多数项目,我使用以下模式:
创建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)
我发现这里的回答很有帮助。(这个问题是否得到了更明确的解决?上一次回复是在一年前。)在考虑了列出的所有方法之后,我提出了一个在这里没有列出的解决方案。
我的标准是:
所有东西都应该在源代码控制中。我不喜欢精细的东西到处乱放。 理想情况下,将设置保存在一个文件中。如果我不看东西,我就会忘记它们:) 无需部署手动编辑。应该能够用一个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总是让它变得如此模糊,以至于你可以设置环境变量。)
使用这种方法,开发设置都在一个(标准)位置,只需在需要的地方覆盖生产设置。任何与开发设置有关的事情都应该完全安全地提交到源代码控制中,而不会对生产产生影响。
我在django split-settings的帮助下管理我的配置。
它是默认设置的临时替换。它很简单,但可配置。并且不需要重构现有设置。
下面是一个小例子(文件示例/settings/__init__.py):
from split_settings.tools import optional, include
import os
if os.environ['DJANGO_SETTINGS_MODULE'] == 'example.settings':
include(
'components/default.py',
'components/database.py',
# This file may be missing:
optional('local_settings.py'),
scope=globals()
)
就是这样。
更新
我写了一篇关于用django-split-sttings管理django设置的博文。看看吧!
创建多个版本的settings.py是12因素应用程序方法论的反模式。 请使用python- decoupling或django-environ。