如何configurationDjango进行简单的开发和部署？
我倾向于在做Django开发时使用SQLite ，但是在实时服务器上经常需要更强大的function（例如MySQL / PostgreSQL ）。 总而言之，Django环境还有其他一些变化：不同的日志位置/强度，媒体path等
你如何pipe理所有这些变化，使部署简单，自动化的过程？
更新： Djangoconfiguration已经发布，这可能是大多数人比手动更好的select。
如果你更喜欢手动做事情，我以前的答案仍然适用：
我有多个设置文件。
-
settings_local.py– 主机特定的configuration，如数据库名称，文件path等 -
settings_development.py– 用于开发的configuration，例如DEBUG = True。 -
settings_production.py– 用于生产的configuration，例如SERVER_EMAIL。
我将这些与一个settings.py文件结合在一起，首先导入settings_local.py ，然后导入其他两个之一。 它决定在settings_local.py使用两个设置加载哪一个 – DEVELOPMENT_HOSTS和PRODUCTION_HOSTS 。 settings.py调用platform.node()来查找正在运行的机器的主机名，然后在列表中查找该主机名，并根据find主机名的列表加载第二个设置文件。
这样，你真正需要担心的唯一事情就是使settings_local.py文件保持与主机特定的configuration保持一致，并且其他的一切都是自动处理的。
看看这里的一个例子。
就个人而言，我使用一个settings.py项目，我只是看它的主机名（我的开发机器有主机名以“gabriel”开头，所以我只是有这样的：
import socket if socket.gethostname().startswith('gabriel'): LIVEHOST = False else: LIVEHOST = True
那么在其他地方我有这样的事情：
if LIVEHOST: DEBUG = False PREPEND_WWW = True MEDIA_URL = 'http://static1.grsites.com/' else: DEBUG = True PREPEND_WWW = False MEDIA_URL = 'http://localhost:8000/static/'
等等。 less一点可读性，但它工作正常，并节省不得不玩弄多个设置文件。
在settings.py结束时，我有以下几点：
try: from settings_local import * except ImportError: pass
这样，如果我想要覆盖默认设置，我只需要把settings_local.py放在settings.py的旁边。
我有两个文件。 包含常用/默认设置的settings_base.py，以及选中到源代码pipe理中的settings_base.py。 每个部署都有一个单独的settings.py ，它将from settings_base import *开始执行，然后根据需要进行覆盖。
我发现最简单的方法是：
1）使用默认settings.py为本地开发和2）创build一个production-settings.py开始：
import os from settings import *
然后只是覆盖生产中不同的设置：
DEBUG = False TEMPLATE_DEBUG = DEBUG DATABASES = { 'default': { .... } }
有一点相关，关于在多个数据库中部署Django本身的问题，你可能想看看Djangostack 。 您可以下载一个完全免费的安装程序，允许您安装Apache，Python，Django等。作为安装过程的一部分，我们允许您select要使用的数据库（MySQL，SQLite，PostgreSQL）。 我们在内部自动部署（可以在无人参与模式下运行）时广泛使用安装程序。
我有我的settings.py文件在外部目录中。 这样，它不会被检入到源代码控制中，也不会被部署覆盖。 我把它放在我的Django项目下的settings.py文件中，以及任何默认设置：
import sys import os.path def _load_settings(path): print "Loading configuration from %s" % (path) if os.path.exists(path): settings = {} # execfile can't modify globals directly, so we will load them manually execfile(path, globals(), settings) for setting in settings: globals()[setting] = settings[setting] _load_settings("/usr/local/conf/local_settings.py")
注意：如果你不能信任local_settings.py，这是非常危险的。
除了Jim提到的多个设置文件之外，我还倾向于将两个设置放置在我的settings.py文件的顶部BASE_DIR和BASE_URL设置为代码的path和网站的基地址，所有其他设置被修改以追加到这些。
BASE_DIR = "/home/sean/myapp/"例如MEDIA_ROOT = "%smedia/" % BASEDIR
所以当移动项目时，我只需要编辑这些设置，而不是search整个文件。
我还build议看一下fabric和Capistrano （Ruby工具，但可以用来部署Django应用程序），这有助于远程部署的自动化。
我认为这取决于网站的规模，是否需要加强使用SQLite，我已经成功地在几个较小的活网站上使用SQLite，并且运行良好。
那么，我使用这个configuration：
在settings.py结尾：
#settings.py try: from locale_settings import * except ImportError: pass
在locale_settings.py中：
#locale_settings.py class Settings(object): def __init__(self): import settings self.settings = settings def __getattr__(self, name): return getattr(self.settings, name) settings = Settings() INSTALLED_APPS = settings.INSTALLED_APPS + ( 'gunicorn',) # Delete duplicate settings maybe not needed, but I prefer to do it. del settings del Settings
我使用环境：
if os.environ.get('WEB_MODE', None) == 'production' : from settings_production import * else : from settings_dev import *
我相信这是一个更好的方法，因为最终你需要针对你的testing环境进行特殊的设置，并且你可以很容易地把它添加到这个条件中。
实际上，您可能应该考虑为您的开发和生产环境configuration相同（或几乎相同）的configuration。 否则，像“嘿，它在我的机器上工作”的情况会不时发生。
所以为了自动部署并消除这些WOMM问题，只需使用Docker即可 。
