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

早在2012年二月份时，我写了一篇题为”以正确的方式开始一个Django项目“的文章，紧随的是“以正确的方式开始一个 Django 1.4 项目”（OSC翻译地址）。这两篇文章得到了连续的关注，并在StackOverflow回答、维基参考以及Tweets上被援引了多次。现在Django1.5和1.6已经出来了，似乎是应该更新文章了。

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

文章结束时，你将有

1. 一个全功能的Django 1.6项目

2. 源代码受控的所有资源（使用Git或Mercurial）

3. 自动回归和单元测试（使用unittest库）

4. 一个独立于特定环境的安装项目（使用virtualenv）

5. 自动化的部署和测试(使用Fabric)

6. 自动数据库迁移 (使用South)

7. 一个标度你站点的开发工作流程

除第一部在官方教程中外其他部分教程里都没有。它们应该这样。如果你想开始一个新的、生产就绪的Django 1.6项目，请继续往下看。

先决条件

假定你已了解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/.virtualenvsexport PROJECT_HOME=$HOME/directory-you-do-development-insource /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/Python项目并且和许多开发者讨论过。一个具有压倒性的事实是，那些具有最多困难的事情往往都没有使用任何的版本控制。这听起来让人难以置信(想想GitHub的流行程度吧)，但是开发者们根本不会去接触版本控制。也有一些人认为"这是个小项目"，没有必要使用版本控制。这是错误的。

这里列出的工具不会让你为了使用版本控制而增加更多额外的支出。

之前，我只提到过git作为(D)VCS。但是，既然这个项目是Python写的，Mercurial也是一个基于Python的不错的选择。因为两者都比较流行，所以你能找到许多在线学习资源。确保你已经安装了git或者Mercurial。两者都可以通过你的distro's packaging系统获取它们。

如果你打算用git，GitHub显然是一个很好的选择可以把你的代码保存到远程仓库里。使用Mercurial的话， Atlassian的Bitbucket是一个不错的选择(它也支持git，所以你用git或者Mercurial都行)

（源码）控制你的环境

即使我们还没真正做什么，但我们知道我们想让所有东西都在源码控制下。我们有两类“东西”将提交：你的代码本身（包括模板，等等）和支持文件，像数据库夹具、South迁移（以后会更多）和requirements.txt文件，列出你的项目依赖的所有包，允许自动构建环境（不需要再次使用pip install安装所有包）。

让我们开始创建我们的项目文件夹。使用django-admin.py提供的startproject命令来设置。

$ django-admin.py startproject django_project

我们将看到创建了一个单独的文件夹：django_project。在django_project文件夹内，我们将看到 另一个包含了常见元素的django_project文件夹：setting.py，urls.py和wsgi.py。在第二个django_project文件夹的同一级内有manage.py文件。

插曲：项目vs.应用程序

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

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

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

创建仓库

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

git

$ git init

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

$ git add django_project

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

$ git commit -m 'Initial commit of django_project'

Mercurial

$ hg init

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

$ hg add django_project

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

$ hg commit -m 'Initial commit of django_project'

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

使用South进行数据库迁移

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

何时开始使用South

在前面的文章中，我建议在项目的一开始就使用South。对于相对简单的项目而已，这挺好。然而，如果在你的原型中有大量的模型有很大的变化，那现在不是使用South的时候。对应的，仅仅丢掉并在需要时重建数据库。你可以编写脚本来构成拥有一些测试数据的数据库，并在需要时编辑它们。然而，一旦你的模型不再变化，尽快开始使用South。这很简单：

./manage.py convert_to_south <app_name>

安装和设置

仍然在我们的虚拟环境下，像这样安装South：

$ pip install south

我们在项目的settings.py文件中把South添加到INSTALLED_APS中。现在就添加，包括你的项目中的数据库设置，然后运行python manage.py syncdb。你将需要提升权限使用超级用户名和密码（你可以输入然后回车）。更重要的是，South已经在数据库中设置好了它需要用的表格。

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

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