全面剖析Python的Django框架中的項目部署技巧第1/2頁

文章結束時，你將有

除第一部在官方教程中外其他部分教程里都沒有。它們應該這樣。如果你想開始一個新的、生產就緒的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等）

代碼如下:

重載一下你的啟動配置文件(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 

安裝和設置

仍然在我們的虛擬環境下，像這樣安裝South：

$ pip install south

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

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

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

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

(git)

$ git status
# On branch master
# Changes not staged for commit:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
## modified: django_project/settings.py
## Untracked files:
# (use "git add ..." 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，你可能發現一些你永遠都不希望提交的文件，例如上面出現的 python 編譯 后的 .pyc 文件，以及 vim 的.swp 交換文件。要忽略這些文件，在項目的根目錄中創建一個 .gitignore 或 .hgignore 文件，并在其中添加匹配你不希望追蹤的文件的 shell 模式。例如，我的文件內容多半就是：
?

代碼如下:

在我們提交之前，還有一個信息需要查看：我們已經安裝的 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'

新型設置

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

在setting.py內，INSTALLED_APPS會很快變成一堆第三方的包，自身django應用和項目特定的應用。我習慣把INSTALLED_APPS分成三個類別：

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

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

INSTALLED_APPS = DEFAULT_APPS + THIRD_PARTY_APPS + LOCAL_APPS

否則，Django將會出現沒有定義INSTALLED_APPS的錯誤。

創建我們的應用

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

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

$ python manage.py schemamigration myapp --initial

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

$ python manage.py migrate myapp

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

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

$ python manage.py schemamigration myapp --auto

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

開發區域

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

在你的開發目錄，使用git或Mercurial克隆當前項目：

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

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

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

$ git checkout -b 

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

$ hg branch 

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

使用 Fabric 來進行部署

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

$ pip install fabric

Fabric 需要一個名為fabfile.py的 fabfile 文件，這個文件定義了所有我們可以采用的動作。現在我們就來創建它。將下面這些內容寫入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')

這樣就會運行這個測試并提交你的變更，但是提交只在測試通過的條件下發生。在此處，生產環境中一個簡單的"pull"動作都可以成為實際部署。我們給實際部署再增加一些東西。將以下內容增加到fabfile.py：
當前1/2頁 12下一頁

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com