在svn/hg/git/etc中优雅地处理特定于站点的设置/配置?

Par*_*and 24 django version-control configuration

我一直在寻找一种更好的方法来处理特定于站点的设置(在这种情况下,django settings.py文件).

settings.py结构和字段相当一致,但开发人员的框,集成,QA,测试和生产环境之间的值不同.

控制设置源同时仍然允许在不同框之间进行更改的优雅方法是什么?

我也担心在源代码管理中有敏感数据(例如数据库密码),但我确实想要自动部署.

我们使用过的例子:

  • settings.py设置公共值,然后根据主机名或用户名加载辅助设置文件.

  • 使用部署脚本将值注入settings.py文件.但这只是将问题转移到管理部署脚本而不是settings.py脚本.

有人有一个特别优雅的方法吗?

Ned*_*der 18

创建一个主要的settings.py文件,其中应包括:

# Pull in hostname-based changes.
import socket
HOSTNAME = socket.gethostname().lower().split('.')[0].replace('-','')

try:
    exec "from myproject.settings.host_%s import *" % HOSTNAME
except ImportError:
    pass

# Pull in the local changes.
try:
    from myproject.settings.local import *
except ImportError:
    pass
Run Code Online (Sandbox Code Playgroud)

现在,为您关心的每个主机名创建一个新的设置文件.但这些都很小.每个生产服务器的文件都包含:

from myproject.settings.production import *
Run Code Online (Sandbox Code Playgroud)

并且您的登台服务器具有:

from myproject.settings.staging import *
Run Code Online (Sandbox Code Playgroud)

现在,您可以创建一个production.py文件,其中包含设置的生成覆盖,staging.py等.您可以为服务器播放的每个角色创建新文件.

最后,您可以在具有本地覆盖的任何计算机(包括开发人员的计算机)上创建local.py文件,并将此文件标记为源控件忽略,以便不会检入更改.

我们已经使用了这种结构多年,它的效果非常好.

  • 这似乎是一个很好的方法,但我很难弄清楚你的目录结构.你有一个settings.py以及一个设置包/目录吗?如果是这样,你如何避免命名冲突?(对不起,如果真的很明显). (3认同)