为本地开发和生产服务器处理设置的推荐方法是什么?其中一些(如常量等)可以在两者中更改/访问,但其中一些(如静态文件的路径)需要保持不同,因此不应该在每次部署新代码时都重写。
目前,我正在将所有常量添加到settings.py中。但是每次我在本地更改一些常量时,我都必须将其复制到生产服务器并编辑文件以进行特定于生产的更改……:(
编辑:看起来这个问题没有标准答案,我已经接受了最流行的方法。
为本地开发和生产服务器处理设置的推荐方法是什么?其中一些(如常量等)可以在两者中更改/访问,但其中一些(如静态文件的路径)需要保持不同,因此不应该在每次部署新代码时都重写。
目前,我正在将所有常量添加到settings.py中。但是每次我在本地更改一些常量时,我都必须将其复制到生产服务器并编辑文件以进行特定于生产的更改……:(
编辑:看起来这个问题没有标准答案,我已经接受了最流行的方法。
当前回答
不要使用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。没有重新导入黑客。
其他回答
不要使用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。没有重新导入黑客。
我认为最好的解决方案是@T提出的。但是我不知道为什么在Django中不使用DEBUG标志。我写下面的代码为我的网站:
if DEBUG:
from .local_settings import *
简单的解决方案总是比复杂的解决方案好。
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是一个活动代码文件。假设您没有在生产中设置DEBUG(这是一个最佳实践),您可以执行如下操作:
if DEBUG:
STATIC_PATH = /path/to/dev/files
else:
STATIC_PATH = /path/to/production/files
非常基本,但是理论上,您可以根据DEBUG的值或您想使用的任何其他变量或代码检查来提高任何复杂级别。
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__)))
通过这种方式,项目总监可以结构化,并且可以在生产和本地开发之间进行管理。