我認爲您需要更多關於您部署的網站類型的信息：根據網站之間的關係，以編程方式和「合法」方式（如在商業關係中）存在差異：
如果你是一個網頁設計師和程序員有幾個客戶，那麼你可能會從分離受益 -
- 具有每「現場」的系統帳戶，如果網站是「擁有」不同的人都能得心應手。
- 如果您的網站是相關的，即論壇網站，博客網站等，您可能會受益於單一部署系統（如我們的）。
- 對於圖書館來說，如果它們是在信譽良好的資源（pypy，github等）上託管的，那麼它可能會將它們留在那裏並從它們進行部署 - 如果它們位於宕機的主機上，並把它們放在我們的git倉庫的第三方文件夾中。
FABRIC 面料是驚人的 - 如果配置適合你的設置和：
- 在這裏，我們有一個政策，這意味着沒有人需要登錄到服務器（這是大多真的 - 有時候我們想看看原始的nginx日誌文件，但它很少見）。
- 我們有布配置，以便有各個功能塊（restart_nginx，restart_uwsgi等），而且其運行的所有小塊以正確的順序
- 更高級別的「生意」功能 - 爲我們所有更新我們的服務器我們小心地輸入'fab -i secretkey實時部署' - 實時設置活動服務器的設置，並部署ldeploys（-i是可選的，如果你有。ssh密鑰設置正確）
- 我們甚至有一個控制標誌，如果使用實時設置，它會在執行部署之前詢問'您確定'。
我們的代碼佈局
所以我們的代碼庫的佈局看起來有點像這樣：因爲我們我們的二進制文件加載到我們的回購，但它意味着
/ <-- folder containing readme file etc
/bin/ <-- folder containing nginx & uwsgi binaries (!)
/config/ <-- folder containing nginx config and pip list but also things like pep8 and pylint configs
/fabric/ <-- folder containing fabric deployment
/logs/ <-- holding folder that nginx logs get written into (but not committed)
/src/ <-- actual source is in here!
/thirdparty/ <-- third party libs that we didn't trust the hosting of for pip
可能有爭議，如果我升級nginx，並想要回滾，我只是通過操縱git來完成。我知道什麼是對什麼構建有效。
我們的部署工作原理：
我們所有的源代碼託管在一個私人到位桶回購（我們有很多回購和少數用戶的，這就是爲什麼到位桶對我們來說是更好的，然後github上）。我們有一個用於'服務器'的用戶帳戶，它有自己的bitshcket的ssh密鑰。
部署在織物執行每個服務器上的以下：
- IRC機器人宣佈開始到IRC頻道
- GIT中拉
- PIP部署（從一個PIP列表中我們回購）
- syncdb
- south migrate
- uwsgi restart
- 芹菜重啓
- IRC bot的公佈完成情況納入IRC頻道
- 開始可用性測試
- 宣佈可用性測試（或後報告爲民營引擎收錄）
的「可用性測試」的結果（因爲單位測試，但針對實時服務器） - 點擊「測試」帳戶上的所有網頁和API，以確保其獲取正常數據而不影響實時統計數據。
我們也有一個備份git的服務，所以如果到位桶下跌，它落在了該擺好，我們甚至有詹金斯整合上提交的「部署」分支，它會導致部署要經過
嚇人的位
因爲我們使用雲計算和期待高吞吐量，我們的盒子自動重生。 Theres是一個包含git repo等副本的默認映像，但總是會過期的，所以它們是一個啓動腳本，它自動部署，這意味着添加到集羣的新框自動更新。
這可能會被關閉，因爲這裏真的有4個問題。我保持一切簡單，並把我所有的網站放在'/ sites/www.mysite.com /'下。在特定站點的文件夾中，我有一個'project'文件夾，其中包含需要檢入VCS的特定於該站點的* everything *文件夾，包括配置，設置，自述文件，要求等。 – 2012-04-05 10:37:58