Django + SVN +部署

Question

我是版本控制的强力支持者,我正在开始研究Django项目.我以前做了一些,并尝试了一些不同的方法,但我还没有找到一个体面的结构,我真的觉得舒服.

这就是我想要的:

a)将源代码签入版本控制

b)最好不要将环境检入版本控制(类似于buildout或pip requirements.txt适用于设置环境)

c)一个合理的"让新开发者开始"的故事

d)合理的部署故事 - 最好是整个部署环境可以由服务器上的脚本生成

在我看来,之前有人必须这样做,但是许多小时的搜索都导致半生不熟的解决方案并没有真正解决所有这些问题.

关于我应该在哪里看的任何想法？

Answer 1

我在我的主目录中保留了一个projects/目录（在Linux上）。当我需要开始一个新项目时，我会在projects/中创建一个新的、名称简短（足以描述该项目）的目录；这将成为该项目的新 virtualenv（带有 --no-site-packages）的根。

在该目录中（在我安装了 venv、获取它并安装了我将使用的 django 副本之后），我“django-admin.py startproject”是一个子目录，通常使用相同的短名称。无论项目有多小，该目录都会成为我的 hg repo 的根目录（带有快速的 hg init 和 ci）。

如果有机会与其他开发人员共享项目（例如工作项目），我会在存储库根目录中包含一个 pip requests.txt。那里只有项目需求；例如，django-debug-toolbar 和 django-extensions（我的开发工作流程的主要内容）不是项目需求。当我们使用它时，南方是。

对于 django 项目，我通常保留默认的 settings.py，可能进行一些更改，并将 local_settings 约定添加到它的末尾（try: from local_settings import *; except ImportError: pass）。我和其他开发人员的特定环境设置（例如，向已安装的应用程序添加 django-extensions 和 django-debug-toolbar）位于 local_settings.py 中，该设置未签入版本控制。为了帮助新开发人员，您可以提供该文件的模板作为 local_settings.py.temp 或其他不会用于任何其他目的的名称，但我发现这不必要地使存储库变得混乱。

对于个人项目，如果我计划公开发布，我通常会包含一个自述文件。在工作中，我们维护 Trac 环境和良好的沟通，以使新开发人员加快项目进度。

至于部署，正如 rz 提到的，我听说 Fabric 非常适合这种自动化本地/远程脚本编写，尽管我自己还没有真正抓住机会去研究它。

对于新手来说，典型的 shell 会话可能如下所示：

$ cd ~/projects/
$ mkdir newproj
$ cd newproj/
$ virtualenv --no-site-packages .
$ source bin/activate
(newproj)$ pip install django django-debug-toolbar django-extensions
... installing stuff ...
(newproj)$ django-admin.py startproject newproj
(newproj)$ cd newproj/
(newproj)$ hg init .; hg ci -A -m "Initial code"