項目開始時是一個關(guān)鍵時刻，選擇會對項目產(chǎn)生長期的影響。有很多關(guān)于如何開始使用Django框架的教程，但很少討論如何專業(yè)地使用Django，或如何使用行業(yè)公認的最佳做法來確保你的項目規(guī)模的持續(xù)增長。事前的籌劃讓你(和所有同事的生活)在走向?qū)頃r更容易。

文章結(jié)束時，你將有

•     一個全功能的Django 1.6項目
•     源代碼受控的所有資源（使用Git或Mercurial）
•     自動回歸和單元測試（使用unittest庫）
•     一個獨立于特定環(huán)境的安裝項目（使用virtualenv）
•     自動化的部署和測試(使用Fabric)
•     自動數(shù)據(jù)庫遷移 (使用South)
•     一個標(biāo)度你站點的開發(fā)工作流程

除第一部在官方教程中外其他部分教程里都沒有。它們應(yīng)該這樣。如果你想開始一個新的、生產(chǎn)就緒的Django 1.6項目，請繼續(xù)往下看。

先決條件

假定你已了解Python的基本知識，同時，以往的一些Django經(jīng)驗會有幫助，但這不是必要的。你需要git或Mercurial來進行版本控制。就這些！
準(zhǔn)備安裝

我假設(shè)你已經(jīng)安裝了Python。如果你沒有的話到python.org找到與你系統(tǒng)架構(gòu)相符的版本下載安裝。我使用一個Linode上的64位的Ubuntu服務(wù)器，我很高興使用Linode的服務(wù)。

那么，第一步是什么呢？安裝Django？不完全是。將安裝包直接安裝到你當(dāng)前的site-packages里有一個常見的問題：如果你的機器上有一個以上的Python項目使用Django等其他庫，你可能會碰到應(yīng)用和安裝軟件庫之間依賴性的問題。因此，我們將使用virtualenv和它的延展virtualenvwrapper來管理我們的Django安裝。這是Python和Django用戶的實踐建議。

如果你使用pip來安裝第三方庫（我不明白你為什么不），你可以通過簡單的操作安裝virtualenv和virtualenvwrapper。
 

$ pip install virtualenvwrapper

安裝完后，將下附內(nèi)容添加到你的shell啟動配置文件中（.zshrc、.bashrc、.profile等）
 

重載一下你的啟動配置文件(source .zshrc)，現(xiàn)在你已經(jīng)就緒了。

創(chuàng)建一個新環(huán)境

創(chuàng)建一個虛擬環(huán)境很簡單，只需輸入
 

$ mkvirtualenv django_project

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

你會注意到立馬發(fā)生的一些事情：

    你的shell前面加上了“（django_project）”

    distribute和pip被自動安裝了

這里是virtualenvwrapper的一個很有用的部分：它會自動為你準(zhǔn)備好環(huán)境，讓你馬上可以使用pip安裝庫?！埃╠jango_project）”的部分是提醒你正在使用的是virtualenv而不是你系統(tǒng)上的Python。要退出虛擬環(huán)境只需簡單輸入deactivate即可。當(dāng)你要回到你的項目開始工作時，只需使用workon django_project即可。需要注意的是這與vanilla virtualenv工具不同，在哪里運行這些命令都可以。

安裝Django

“等一下，‘安裝Django'？我已經(jīng)安裝Django了！”，太好了。不過你不會用它的。相反，我們將使用機器上的一個被virtualenv管理的且不會被其他用戶（或你自己）弄亂的Django安裝。在virtualenv中安裝Django，只需輸入：
 

$ pip install django

這樣最新版的Django將被安裝在你的virtualenv環(huán)境里，你可以這樣確認：
 

$ which django-admin.py

這會指出你的$HOME/.virtualenvs/目錄。如果沒有的話，確認你的輸入提示里有“（django_project）”。如果沒有，使用workon django_project激活virtualenv。

建立項目

在我們真正開始這個項目之前，我們先來談一談。我在過去的幾年里咨詢過很多Django/Python項目并且和許多開發(fā)者討論過。一個具有壓倒性的事實是，那些具有最多困難的事情往往都沒有使用任何的版本控制。這聽起來讓人難以置信(想想GitHub的流行程度吧)，但是開發(fā)者們根本不會去接觸版本控制。也有一些人認為"這是個小項目"，沒有必要使用版本控制。這是錯誤的。

這里列出的工具不會讓你為了使用版本控制而增加更多額外的支出。

之前，我只提到過git作為(D)VCS。但是，既然這個項目是Python寫的，Mercurial也是一個基于Python的不錯的選擇。因為兩者都比較流行，所以你能找到許多在線學(xué)習(xí)資源。確保你已經(jīng)安裝了git或者Mercurial。兩者都可以通過你的distro's packaging系統(tǒng)獲取它們。

如果你打算用git，GitHub顯然是一個很好的選擇可以把你的代碼保存到遠程倉庫里。使用Mercurial的話， Atlassian的Bitbucket是一個不錯的選擇(它也支持git，所以你用git或者Mercurial都行)

（源碼）控制你的環(huán)境

即使我們還沒真正做什么，但我們知道我們想讓所有東西都在源碼控制下。我們有兩類“東西”將提交：你的代碼本身（包括模板，等等）和支持文件，像數(shù)據(jù)庫夾具、South遷移（以后會更多）和requirements.txt文件，列出你的項目依賴的所有包，允許自動構(gòu)建環(huán)境（不需要再次使用pip install安裝所有包）。

讓我們開始創(chuàng)建我們的項目文件夾。使用django-admin.py提供的startproject命令來設(shè)置。
 

$ django-admin.py startproject django_project

我們將看到創(chuàng)建了一個單獨的文件夾：django_project。在django_project文件夾內(nèi)，我們將看到 另一個包含了常見元素的django_project文件夾：setting.py，urls.py和wsgi.py。在第二個django_project文件夾的同一級內(nèi)有manage.py文件。

插曲：項目vs.應(yīng)用程序

你也許會好奇，在Django1.4中，為什么已經(jīng)有了新建應(yīng)用程序的命令還要增加新建項目的命令。答案在于Django“項目”和Django“應(yīng)用程序”的區(qū)別。簡單來說，一個項目是一套完整的網(wǎng)站或者應(yīng)用。一個“應(yīng)用程序”是一個可以用在任何Django項目中的很小的、（希望是）獨立的Django應(yīng)用。如果你正在構(gòu)建一個叫做“超級博客”的博客應(yīng)用，那么“超級博客”就是你的Django項目。如果“超級博客”支持讀者投票，那“投票”就是被“超級博客“使用的一個Django應(yīng)用程序。這個概念就是需要你的投票應(yīng)用程序可以應(yīng)用在其他需要用戶投票的Django項目中，而不是僅能應(yīng)用在”超級博客“項目中。一個項目就是一堆應(yīng)用程序按照項目特定的邏輯構(gòu)建的一個集合。一個應(yīng)用程序可以應(yīng)用在多個項目中。

盡管你會本能地傾向于在你的“投票”應(yīng)用程序中包含大量"超級博客"的特定代碼和信息，但避免這樣有許多好處?；谒神詈系脑?，將你的應(yīng)用編寫為一個獨立的實體可以保持設(shè)計意圖，并且可以避免項目里的bug直接影響到你的應(yīng)用。這也意味著，如果你希望的話，你可以把你的任何應(yīng)用程序發(fā)給另一個開發(fā)者，且他們不需要訪問或更改你的主項目。

像軟件開發(fā)中的許多事情一樣，這需要一點付出，但回報很豐厚。

創(chuàng)建倉庫

現(xiàn)在我們的項目里已經(jīng)有一些“代碼”了（確實來說只是一些股票腳本和空的配置文件，恕我這樣說），現(xiàn)在是我們初始我們源碼控制庫再好不過的時間了。下面是在Git和Mercurial中實現(xiàn)的步驟。
git
 

$ git init

這條命令在當(dāng)前目錄創(chuàng)建了一個git倉庫。將我們所有的文件添加到git以便提交。
 

$ git add django_project

現(xiàn)在，我們將代碼切實提交到我們的新庫中：
 

$ git commit -m 'Initial commit of django_project'

Mercurial
 

$ hg init

這條命令在當(dāng)前目錄創(chuàng)建了一個Mercurial倉庫。將我們所有的文件添加到git以便提交。
 

$ hg add django_project

現(xiàn)在，我們將代碼切實提交到我們的新庫中：
 

$ hg commit -m 'Initial commit of django_project'

如果你打算使用像GitHub或者Bitbucket，現(xiàn)在是時候把代碼push上去了。

使用South進行數(shù)據(jù)庫遷移

Django中最令人沮喪的特性之一是管理模型的變化和數(shù)據(jù)庫的相關(guān)變化。有了South的幫助，你可以實現(xiàn)創(chuàng)建一個完整的應(yīng)用，而不需要寫具體的數(shù)據(jù)庫代碼。South會創(chuàng)建一個遷移文件來檢測你的模型變化，并自動在數(shù)據(jù)庫中生成。這使得你既可以前向根據(jù)最新變化來遷移數(shù)據(jù)庫，又可以后向取消一個變化或者一系列變化。它讓你的生活如此簡單，Django發(fā)行版沒有包含它真讓人吃驚。

何時開始使用South

在前面的文章中，我建議在項目的一開始就使用South。對于相對簡單的項目而已，這挺好。然而，如果在你的原型中有大量的模型有很大的變化，那現(xiàn)在不是使用South的時候。對應(yīng)的，僅僅丟掉并在需要時重建數(shù)據(jù)庫。你可以編寫腳本來構(gòu)成擁有一些測試數(shù)據(jù)的數(shù)據(jù)庫，并在需要時編輯它們。然而，一旦你的模型不再變化，盡快開始使用South。這很簡單：
 

./manage.py convert_to_south <app_name>

安裝和設(shè)置

仍然在我們的虛擬環(huán)境下，像這樣安裝South：
 

$ pip install south

我們在項目的settings.py文件中把South添加到INSTALLED_APS中?，F(xiàn)在就添加，包括你的項目中的數(shù)據(jù)庫設(shè)置，然后運行python manage.py syncdb。你將需要提升權(quán)限使用超級用戶名和密碼（你可以輸入然后回車）。更重要的是，South已經(jīng)在數(shù)據(jù)庫中設(shè)置好了它需要用的表格。

你可能認識到我們并沒有在項目中添加應(yīng)用，而只是運行了 syncdb。先這樣做可以讓 South 在一開始的時候就被安裝。使用 South，在我們應(yīng)用中的所有遷移工作都可以完成，包括初始遷移。

由于我們剛剛完成了很多變更，現(xiàn)在將是一個提交的好時間。你得適應(yīng)頻繁的提交，要知道，提交的粒度越小，在出錯時回退的自由度越高。

要進行提交操作，讓我們看看都有那些修改。

(git)
 

$ 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

(Mercurial)
 

$ 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

使用 git 和 Mercurial，你可能發(fā)現(xiàn)一些你永遠都不希望提交的文件，例如上面出現(xiàn)的   python 編譯 后的 .pyc 文件，以及 vim 的.swp 交換文件。要忽略這些文件，在項目的根目錄中創(chuàng)建一個 .gitignore 或 .hgignore 文件，并在其中添加匹配你不希望追蹤的文件的 shell 模式。例如，我的文件內(nèi)容多半就是：
?
 

在我們提交之前，還有一個信息需要查看：我們已經(jīng)安裝的 Python 包。我們希望能夠追蹤使用到的 Python 包的名稱和版本，這樣一來，我們就可以輕松的重建生產(chǎn)環(huán)境。pip 正好有個命令可以完成我們這個需求。
 

$ pip freeze > requirements.txt

我將 pip 的輸出存入名為 requirements.txt 的文件，并將這個文件添加到代碼控制中。這樣，我們總是擁有一個更新的列表，里面包含了將使用的包。

現(xiàn)在將 settings.py 及 requirements.txt 添加到提交文件中，并提交：
 

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

新型設(shè)置

隨著開發(fā)者對Django和Python越來越舒適，他們會發(fā)覺settings.py就是個簡單的Python腳本，因此可以“編寫”。對settings.py的一個常見方式是從一個頗為古怪的項目文件夾移動到一個新的叫做conf或者config的文件夾。要清楚你需要對manage.py做些小改變來適應(yīng)這個移動。

在setting.py內(nèi)，INSTALLED_APPS會很快變成一堆第三方的包，自身django應(yīng)用和項目特定的應(yīng)用。我習(xí)慣把INSTALLED_APPS分成三個類別：

1.     DEFAULT_APPS：作為默認Django安裝（像admin）的一部分的Django框架應(yīng)用
2.     THIRD_PARTY_APPS:像South
3.     LOCAL_APPS:你創(chuàng)建的應(yīng)用

這可以更容易的看出哪些是你使用的第三方應(yīng)用，哪些是項目自身的。僅僅記住最后有一行和下面相似的代碼：
 

INSTALLED_APPS = DEFAULT_APPS + THIRD_PARTY_APPS + LOCAL_APPS

否則，Django將會出現(xiàn)沒有定義INSTALLED_APPS的錯誤。

創(chuàng)建我們的應(yīng)用

以正常的方式使用manage.py來創(chuàng)建一個應(yīng)用（python manage.py startapp myapp)，并把它加入到INSTALLED_APP中。同時，花費時間讓manage.py可執(zhí)行（chmod +x manage.py），這樣你就可以僅僅輸入./manage.py <command>，而不需要總是輸入python manage.py <command>。老實說，很少有開發(fā)者這么做。我無法搞清楚為什么。

在添加模型前，我們要做的第一件事是我們告訴South我們想用它做遷移：
 

$ python manage.py schemamigration myapp --initial

這將創(chuàng)建一個移植文件，用來應(yīng)用我們對于數(shù)據(jù)庫的模型更改（如果我們有的話），而不需要完全銷毀再重建它。當(dāng)情況偏離時，它也可以讓我們用來 恢復(fù)更改。我們使用移植文件來 移植數(shù)據(jù)庫的變化（即使還沒有變化），命令如下：
 

$ python manage.py migrate myapp

South足夠智能，知道去哪里找到移植文件，也記得我們做的最后的移植。你可以指定單獨的移植文件，但這一般并不是必須的。

當(dāng)我們最終對模型做出改變時，我們使用下面的命令來讓South創(chuàng)建一個移植文件：
 

$ python manage.py schemamigration myapp --auto

這將檢測myapp中的模型，并自動相應(yīng)的添加、刪除或修改數(shù)據(jù)庫中的表。然后使用如上的移植命令就可以將改變應(yīng)用到數(shù)據(jù)庫上。

開發(fā)區(qū)域

還有一件事你需要注意：將開發(fā)區(qū)域與你已經(jīng)確認的文件區(qū)分開，原因顯而易見。使用Git和Mercurial實現(xiàn)這個很簡單，而且也有助于部署。創(chuàng)建django_project所在目錄之外的一個目錄作為你開發(fā)區(qū)域（我把它叫做dev）。

在你的開發(fā)目錄，使用git或Mercurial克隆當(dāng)前項目：
 

$ (git/hg) clone /path/to/my/project/

兩個工具都將創(chuàng)建庫的一份完整拷貝。所有的更改、分支及歷史都將在新庫中可用。從現(xiàn)在起，你應(yīng)該在你的開發(fā)目錄工作。

由于使用Git和Mercurial來進行分支都容易便捷，當(dāng)你切換新分支或站點的大規(guī)模變化時創(chuàng)建分支。下面是兩個工具的實現(xiàn)方法：
(git)
 

$ git checkout -b <branchname>

這不僅創(chuàng)建了一個命名新分支且會將代碼檢出。幾乎所有的開發(fā)工作都應(yīng)該在分支上，這樣主分支可以隨時恢復(fù)。
(Mercurial)
 

$ hg branch <branchname>

請注意，在Mercurial社區(qū)里分支是一個有爭議的話題，目前這里有一些可用的選項，但其中還沒有“顯然正確”的。在這里，我使用命名分支，這可能是最安全且最有益的分支風(fēng)格。任何在branch命令后的提交將在新分支生效。

使用 Fabric 來進行部署

那么我們就有了一個Django應(yīng)用。我們怎么來部署它呢？Fabric。對一個合理大小的項目來說，討論任何其它的東西都是浪費時間。Fabric可用于許多種不同目的，不過在部署方面它確實很出色。
 

$ pip install fabric

Fabric 需要一個名為fabfile.py的 fabfile 文件，這個文件定義了所有我們可以采用的動作。現(xiàn)在我們就來創(chuàng)建它。將下面這些內(nèi)容寫入fabfile.py并將其放到項目的根目錄。
 

from fabric.api import localdef prepare_deployment(branch_name):
  local('python manage.py test django_project')
  local('git add -p && git commit') # or local('hg add && hg commit')

這樣就會運行這個測試并提交你的變更，但是提交只在測試通過的條件下發(fā)生。在此處，生產(chǎn)環(huán)境中一個簡單的"pull"動作都可以成為實際部署。我們給實際部署再增加一些東西。將以下內(nèi)容增加到fabfile.py：
 

最新評論