如何在Django中管理本地和生产设置？

本文翻译自：How to manage local vs production settings in Django?

What is the recommended way of handling settings for local development and the production server? 建议使用什么方式处理本地开发和生产服务器的设置？ Some of them (like constants, etc) can be changed/accessed in both, but some of them (like paths to static files) need to remain different, and hence should not be overwritten every time the new code is deployed. 它们中的某些（例如常量等）可以在两者中进行更改/访问，但是其中一些（例如静态文件的路径）需要保持不同，因此，每次部署新代码时都不应覆盖它们。

Currently, I am adding all constants to settings.py . 目前，我正在将所有常量添加到settings.py 。 But every time I change some constant locally, I have to copy it to the production server and edit the file for production specific changes... :( 但是每次我在本地更改一些常量时，都必须将其复制到生产服务器并编辑文件以进行生产特定更改... :(

Edit: looks like there is no standard answer to this question, I've accepted the most popular method. 编辑：这个问题似乎没有标准答案，我已经接受了最受欢迎的方法。

---

#1楼

参考：https://stackoom.com/question/6P54/如何在Django中管理本地和生产设置

---

#2楼

Instead of settings.py , use this layout: 代替settings.py ，使用以下布局：

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

common.py is where most of your configuration lives. common.py是您大多数配置所在的位置。

prod.py imports everything from common, and overrides whatever it needs to override: prod.py从通用导入所有内容，并覆盖需要覆盖的所有内容：

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

# Production overrides
DEBUG = False
#...

Similarly, dev.py imports everything from common.py and overrides whatever it needs to override. 同样， dev.py从common.py导入所有内容，并覆盖需要覆盖的所有内容。

Finally, __init__.py is where you decide which settings to load, and it's also where you store secrets (therefore this file should not be versioned): 最后， __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..."

What I like about this solution is: 我喜欢这个解决方案的地方是：

1. Everything is in your versioning system, except secrets 除秘密外，一切都在您的版本控制系统中
2. Most configuration is in one place: common.py . 大多数配置位于一个位置： common.py 。
3. Prod-specific things go in prod.py , dev-specific things go in dev.py . PROD-具体的事情中去prod.py ，DEV-具体的东西进去dev.py 。 It's simple. 这很简单。
4. You can override stuff from common.py in prod.py or dev.py , and you can override anything in __init__.py . 您可以覆盖prod.py或dev.py common.py dev.py ，也可以覆盖__init__.py任何内容。
5. It's straightforward python. 这是简单易懂的python。 No re-import hacks. 没有重新导入的黑客。

---

#3楼

Two Scoops of Django: Best Practices for Django 1.5 suggests using version control for your settings files and storing the files in a separate directory: Django的两个摘要：Django 1.5的最佳实践建议对设置文件使用版本控制并将文件存储在单独的目录中：

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

The base.py file contains common settings (such as MEDIA_ROOT or ADMIN), while local.py and production.py have site-specific settings: base.py文件包含通用设置（例如MEDIA_ROOT或ADMIN），而local.py和production.py具有站点特定的设置：

In the base file settings/base.py : 在基本文件settings/base.py ：

INSTALLED_APPS = (
    # common apps...
)

In the local development settings file settings/local.py : 在本地开发设置文件settings/local.py ：

from project.settings.base import *

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

In the file production settings file settings/production.py : 在文件生产设置文件settings/production.py ：

from project.settings.base import *

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

Then when you run django, you add the --settings option: 然后，当您运行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

The authors of the book have also put up a sample project layout template on Github. 该书的作者还在Github上提出了一个示例项目布局模板 。

---

#4楼

Remember that settings.py is a live code file. 请记住，settings.py是实时代码文件。 Assuming that you don't have DEBUG set on production (which is a best practice), you can do something like: 假设您没有在生产环境中设置DEBUG（这是最佳做法），则可以执行以下操作：

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

Pretty basic, but you could, in theory, go up to any level of complexity based on just the value of DEBUG - or any other variable or code check you wanted to use. 这很基本，但是从理论上讲，您可以仅基于DEBUG的值或您要使用的任何其他变量或代码检查，将复杂性提高到任何水平。

---

#5楼

I use a settings_local.py and a settings_production.py. 我使用settings_local.py和settings_production.py。 After trying several options I've found that it's easy to waste time with complex solutions when simply having two settings files feels easy and fast. 尝试了几个选项之后，我发现，简单地拥有两个设置文件就很容易且快捷，很容易在复杂的解决方案上浪费时间。

When you use mod_python/mod_wsgi for your Django project you need to point it to your settings file. 当对您的Django项目使用mod_python / mod_wsgi时，您需要将其指向设置文件。 If you point it to app/settings_local.py on your local server and app/settings_production.py on your production server then life becomes easy. 如果将其指向本地服务器上的app / settings_local.py和生产服务器上的app / settings_production.py，那么生活将变得很轻松。 Just edit the appropriate settings file and restart the server (Django development server will restart automatically). 只需编辑适当的设置文件并重新启动服务器（Django开发服务器将自动重新启动）。

---

#6楼

I use a slightly modified version of the "if DEBUG" style of settings that Harper Shelby posted. 我使用Harper Shelby发布的“ if DEBUG”样式的设置的稍微修改的版本。 Obviously depending on the environment (win/linux/etc.) the code might need to be tweaked a bit. 显然，取决于环境（win / linux / etc），可能需要对代码进行一些调整。

I was in the past using the "if DEBUG" but I found that occasionally I needed to do testing with DEUBG set to False. 我过去使用的是“ if DEBUG”，但发现偶尔需要将DEUBG设置为False进行测试。 What I really wanted to distinguish if the environment was production or development, which gave me the freedom to choose the DEBUG level. 我真正想区分的是环境是生产环境还是开发环境，这让我可以自由选择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'

I'd still consider this way of settings a work in progress. 我仍然会考虑以这种方式设置正在进行的工作。 I haven't seen any one way to handling Django settings that covered all the bases and at the same time wasn't a total hassle to setup (I'm not down with the 5x settings files methods). 我还没有一种方法可以处理涵盖所有基础的Django设置，但同时也没有设置麻烦（我对5x设置文件方法并不感到失望）。