以正确的方式开始一个 Django 1.4 项目 已翻译 100%

早在二月份时，我写了一篇题为‘开始Django项目的正确方式’的文章，八个月后它仍然吸引了一批受众。在这八个月，Django框架已经发布到1.4版，活跃发展及前瞻性的1.5版实验性地支持Python 3.X。伴随这些变化以及新的、可更新的可供Django开发者使用的可用资源的出现，我决定重新审视一下Django项目最佳实践的概念。

项目开始时是一个关键时刻，选择会对项目产生长期的影响。有很多关于如何开始使用Django框架的教程，但很少讨论如何专业地使用Django，或如何使用行业公认的最佳做法来确保你的项目规模的持续增长。事前的筹划让你走向将来时更容易。

文章结束时，你将有

1. 一个全功能的Django 1.4项目
2. 源代码受控的所有资源（使用Git或Mercurial）
3. 自动回归和单元测试（使用unittest库）
4. 一个独立于特定环境的安装项目（使用virtualenv）
5. 自动化的部署和测试(使用Fabric)
6. 自动数据库迁移 (使用South)
7. 一个标度你站点的开发工作流程

除了第一部在官方教程内其他部分都不在。它们应该不在。如果你想开始一个新的、生产就绪的Django 1.4项目，请继续往下看。

先决条件

假定你已了解Python的基本知识，同时，以往的一些Django经验会有帮助，但这不是必要的。你需要git或Mercurial来进行版本控制。就这些！

安装准备

我假设你已经安装了Python。如果你没有的话到python.org找到与你系统架构相符的版本下载安装。我使用一个Linode上的64位的Ubuntu服务器，我很高兴使用Linode的服务。

那么，第一步是什么呢？安装Django？不完全是。将安装包直接安装到你当前的site-packages里有一个常见的问题：如果你的机器上有一个以上的Python项目使用Django等其他库，你可能会碰到应用和安装软件库之间依赖性的问题。因此，我们将使用virtualenv和它的延展virtualenvwrapper来管理我们的Django安装。这是Python和Django用户的实践建议。

如果你使用pip来安装第三方库（我不明白你为什么不），你可以通过简单的操作安装virtualenv和virtualenvwrapper。

$ pip install virtualenvwrapper

安装完后，将下附内容添加到你的shell启动配置文件中（.zshrc、.bashrc、.profile等）

export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/directory-you-do-development-in
source /usr/local/bin/virtualenvwrapper.sh

重载一下你的启动配置文件(source .zshrc)，现在你已经就绪了。

创建一个新环境

创建一个虚拟环境很简单，只需输入

$ mkvirtualenv django_project

“django_project”是你的项目的命名。

你会注意到立马发生的一些事情：你的shell前面加上了”（django_project）”，distribute和pip被自动安装了。

这里是virtualenvwrapper的一个很有用的部分：它会自动为你准备好环境，让你马上可以使用pip安装库。“（django_project）”的部分是提醒你正在使用的是virtualenv而不是你系统上的Python。要退出虚拟环境只需简单输入deactivate即可。当你要回到你的项目开始工作时，只需使用workon django_project即可。需要注意的是这与vanilla virtualenv工具不同，在哪里运行这些命令都可以。

安装Django

“等一下，‘安装Django’？我已经安装Django了！”，太好了。不过你不会用它的。相反，我们将使用机器上的一个被virtualenv管理的且不会被其他用户（或你自己）弄乱的Django安装。在virtualenv中安装Django，只需输入：

$ pip install django

这样最新版的Django将被安装在你的virtualenv环境里，你可以这样确认：

$ which django-admin.py

这会指出你的$HOME/.virtualenvs/目录。如果没有的话，确认你的输入提示里有“（django_project）”。如果没有，使用workon django_project激活virtualenv。

建立项目

在正式开始项目之前，我们需要认真谈一谈。在过去的几个月里，我对很多Django开发者说过，开发困难的是那些不使用版本控制系统的开发者。许多新开发者常常不了解版本控制。另一些开发者觉得“这只是一个小项目”，所以没必要用版本控制。大错特错。

这里列出所有工具，没有一个比使用版本控制系统更加有好处。

以前，我仅提到使用git作为一个(D)VCS。然而，对于使用Python的项目，Mercurial是一个合适的基于Python的替代者。这两个工具都非常流行，网上有丰富的学习资源。确保你安装了git或者Mercurial。这两个工具基本都在你所用发行版的包管理系统中。

如果你打算使用git，Github显然是一个用来存放远程仓库的选择。若是用Mercurial，Atlassian的Bitbucket是一个不错的选择（它也支持git，你可以使用任一方式）。

(源码）控制你的环境

即使还没正式做什么，我们知道我们将需要使用源代码管理所有东西。我们有两种将要提交的“内容”：我们的源码本身（包括模板等），像数据库设备、South迁移（以后会越来越多）和一个需求文件等支持文件。在以前的博文中，我建议提交你的真实虚拟环境，但也有些不错的理由不这么干，至少这不是必须的。使用需求文件可以给你带来很多好处，而不需要额外的开销。

让我们开始创建项目文件夹。使用django_admin.py中的新建项目命令来创建。

$ django_admin.py startproject django_project

我们将看到创建的文件夹：django_project。在django_project文件夹内，我们将看到另一个django_project文件夹，里面包含了一些常见的文件：setting.py，urls.py和wsgi.py。在与第二个django_project同一目录的是manage.py文件。

插曲：项目vs.应用程序

你也许会好奇，为什么已经有了新建应用程序的命令还要增加新建项目的命令。答案在于Django“项目”和Django“应用程序”的区别，这在Django1.4里面有详细的描述。简单来说，一个项目是一套完整的网站或者应用。一个“应用程序”是一个可以用在任何Django项目中的很小的、（希望是）独立的Django应用。如果你正在构建一个叫做“超级博客”的博客应用，那么“超级博客”就是你的Django项目。如果“超级博客”支持读者投票，那“投票”就是被“超级博客“使用的一个Django应用程序。这个概念就是需要你的投票应用程序可以应用在其他需要用户投票的Django项目中，而不是仅能应用在”超级博客“项目中。一个项目就是一堆应用程序按照项目特定的逻辑构建的一个集合。一个应用程序可以应用在多个项目中。

尽管你会本能地倾向于在你的“投票”程序中包含大量"超级博客"的特定代码和信息，但避免这样有许多好处。基于松耦合的原理，讲你的应用编写为一个独立的实体可以保持设计意图，并且可以避免项目里的bug直接影响到你的应用。这也意味着，如果你希望的话，你可以把你的任何应用程序发给另一个开发者，且他们不需要访问或更改你的主项目。

像软件开发中的许多事情一样，这需要一点付出，但回报很丰厚。

建立我们的库

现在我们的项目里已经有一些“代码”了（确实来说只是一些股票脚本和空的配置文件，恕我这样说），现在是我们初始我们源码控制库再好不过的时间了。下面是在Git和Mercurial中实现的步骤。

$ git init

这条命令在当前目录创建了一个git仓库。将我们所有的文件添加到git以便提交。

$ git add django_project

现在，我们将代码切实提交到我们的新库中：

$ git commit -m 'Initial commit of django_project' 

$ hg init

这条命令在当前目录创建了一个Mercurial仓库。将我们所有的文件添加到git以便提交。

$ hg add django_project

现在，我们将代码切实提交到我们的新库中：

$ hg commit -m 'Initial commit of django_project' 

如果你打算使用像GitHub或者Bitbucket，现在是时候把代码push上去了。

使用South进行数据库迁移

Django中最令人沮丧的特性之一是管理模型的变化和数据库的相关变化。有了South的帮助，你可以实现创建一个完整的应用，而不需要写具体的数据库代码。South会创建一个迁移文件来检测你的模型变化，并自动在数据库中生成。这使得你既可以前向根据最新变化来迁移数据库，又可以后向取消一个变化或者一系列变化。它让你的生活如此简单，Django发行版没有包含它真让人吃惊（已经有人谈论在Django中包含数据库迁移工具，只是还没发生）。

依旧在我们的虚拟环境，像这样安装South：

$ pip install south

你可能认识到我们并没有在项目中添加应用，而只是运行了 syncdb。先这样做可以让 South 在一开始的时候就被安装。使用 South，在我们应用中的所有迁移工作都可以完成，包括初始迁移。

由于我们刚刚完成了很多变更，现在是提交的时间了。你得适应频繁的提交，要知道，提交的粒度越小，在出错时回退的自由度越高。

要进行提交操作，让我们看看都有那些修改。

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   django_project/settings.py
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       django_project/.settings.py.swp
#       django_project/__init__.pyc
#       django_project/settings.pyc

$ hg status
M django_project/django_project/settings.py
? django_project/django_project/.settings.py.swp
? django_project/django_project/__init__.pyc
? django_project/django_project/settings.pyc

*.pyc .*swp 

在我们提交之前，还有一个信息需要查看：我们已经安装的 Python 包。我们希望能够追踪使用到的 Python 包的名称和版本，这样一来，我们就可以轻松的重建生产环境。pip 正好有个命令可以完成这个。

$ pip freeze > requirements.txt

我将 pip 的输出存入名为 requirements.txt 的文件，并将这个文件添加到代码控制中。这样，在需要时，我们就有了一个包的列表。

现在将 settings.py 及 requirements.txt 添加到提交文件中，并提交：

$ (git/hg) add django_project/settings.py requirements.txt
$ (git/hg) commit -m 'Added South for database migrations'