我正在使用源代碼控制,腳本和部署過程來管理一些web應用程序項目,如wordpress,phpbb和自定義web應用程序。多年來,我對這些進行了改進,現在我有一個很好的框架,對我來說似乎很好,所以它可能適合其他面臨類似問題的人。
以下是有關整體策略的一些基本要點:
- 我從來沒有在生產服務器上SCM和源文件。我沒有看到任何理由把它放在那裏,通常我不希望這些存儲庫在服務器違反的情況下公開。生產服務器上的應用程序只有清理最新穩定版本。沒有項目文件,文檔,單元測試等。任何不需要的東西都不存在。從安全性和應用程序穩定性的角度來看,我認爲這非常重要。
- 不把它變成SCM辯論,但我發現,爲了我的目的,mercurial(和git)在任何方面都比SVN好。您不需要任何「服務器」,並且存儲庫更容易維護。
- 我爲每個項目保留單獨的存儲庫。Mercurial存儲庫既便宜又輕便。將每個項目保存在其自己的存儲庫中可提供極大的靈活性所以沒有一個大型的「public_html」存儲庫。
- 我在開發機器上使用本地的mercurial倉庫。一切都按原樣備份(使用任何備份策略 - 額外的機器,外部驅動器,雲備份)。共享代碼和提供項目目錄一樣簡單。有時候我會保留在dropbox的存儲庫,所以我可以從任何地方訪問它們。
- 部署由部署腳本自動完成(稍後詳細介紹)。其中導出所需的修訂版本,將其編輯並上載到服務器。
- 數據庫轉儲不存儲在SCM中。對於任何真實的項目來說都不實際。我將數據庫結構的轉儲存儲在SCM中,並在結構更改時對其進行更新(我使用mysql dump或phpmyadmin進行更新)。有時將結構數據的轉儲與結構一起存儲在SCM中(具有默認值,查找值等的表)是有意義的。
- 數據庫備份是通過在生產服務器上運行的自動腳本(automysqlbackup工作正常)完成的。轉儲數據庫,歸檔它並旋轉文件(每月,每週,每日)。還有一個腳本,每天將備份轉儲文件下載到非現場位置。這適用於數據量相對較小的項目。顯然,這需要改變大型數據庫。
- 我通常爲開發和生產保留獨立的數據庫實例。儘可能少地使用生產數據庫。當我需要測試/調試某些東西時,我會用實時數據的副本更新我的開發數據庫。
- 有時我在生產服務器上有第二個副本用於分段/單元測試,但在這裏描述太多了。
- 所有部署都通過SSH進行隧道傳輸,SSH是服務器上唯一允許的連接(當然除了http/s)。我將SSH密鑰文件保存在開發機器上。或者,您可以使用VPN作爲隧道。
- 我假設linux/BSD生產服務器。所有這些在Windows服務器上將完全不同(通常更難)。我在Windows,Mac和Linux開發機器上使用這些程序,所有工具都可用。
因此,要回答您的一些問題,我會以相反的方式做。從開發機器上的工作環境開始(完成Web服務器和數據庫)。讓你的應用程序在那裏工作和測試。根據需要將更改提交到本地存儲庫。應用程序準備好部署後,運行部署腳本以自動更新生產站點。
我的部署腳本做這樣的事情:
- 出口所需的修訂本地臨時部署目錄(水銀,GIT中,SVN都從你的資料庫創建工作目錄導出命令)
- 修改已部署的目錄以使其適合實時部署。這包括修改配置文件,更改數據庫名稱,路徑,日誌設置,調試級別等。使用腳本,sed,awk,grep或任何命令行工具所需的。
- 如果需要,從SCM修訂數據生成version.txt(或其他名稱)文件,部署日期等。這將被上傳到服務器。
- 將我的SSH密鑰添加到SSH代理(以避免每次都使用密碼)。
- 使用rsync通過SSH隧道將所有內容同步到服務器。服務器需要正確配置爲rsync目標。使用rsync exclude/include過濾器來排除一切不需要的東西(通常它是。*,除了.htaccess)。
- 如果需要,可以使用SSH遠程執行功能在服務器上運行命令,以執行設置特殊權限(例如,對Wordpress上載目錄的寫入權限)等任務。
- 給我一個很好的「部署成功」消息:)
就是這樣,一旦劇本到位的部署變得輕鬆有趣。運行腳本,轉到實時服務器以查看一切正常,完成。
希望這會有所幫助。
感謝您的工作流程的詳細介紹。這是非常有用的,對於我來說,設置我的源代碼管理和部署過程似乎是一個很好的起點。那麼採用你的方法,你會爲靜態頁面,MediaWiki,WordPress分別存儲Mercurial存儲庫? – 2011-02-11 14:50:35