用Web Deploy發佈ASP.NET MVC2網站

Question

我目前使用Web Deploy，http://learn.iis.net/page.aspx/346/web-deploy/發佈我的MVC2應用程序。它曾經運行良好，但現在它已經到了我無法繼續使用它的程度：

當MVC應用程序很小，只有很少的用戶時，它很容易發佈。只需右鍵單擊Visual Studio中的項目，然後選擇「發佈」。而且由於只有少數用戶，很容易找到無人使用該站點進行快速更新的時間。

然後，該應用程序變得更大，並有更多的用戶。 「發佈」行動開始時間越來越長，偶爾會超時。即使在部署之前回收應用程序池，仍需要很長時間。

此外，它變得更難找到一個時間，當沒有人使用該網站，因此更新可以完成而不會影響任何人。

然後「發佈」行動開始超時每一次，我不得不切換到手動部署按照這個較早的懸而未決的問題：Visual Studio 2010 - web deploy times out - what to do?

現在手動部署所用的時間越來越長，從5到20分鐘。用戶數量顯着增長，因此部署總是會影響某人（響應時間較慢，超時，站點不可用等）

那麼我該怎麼做？有沒有更好的選擇使用Web部署？

編輯：

今天的部署需要18分鐘才能發佈49個已更改的文件。這種情況很荒謬，是我們現在最大的弱點之一。所以我開始一個體面的大小的獎金，希望解決這個問題。

一些更多的問題，這可能會導致一個解決方案：

• 它爲什麼會花這麼長時間時，只有少數文件已改變？
• 爲什麼Web部署zip始終包含整個代碼庫而不僅僅是更改的文件？
• 爲什麼我不自己手動複製已更改的文件並跳過整個Web部署？但是很難手動確定哪些文件已經改變。我使用SVN - 它是否有辦法只輸出兩個分支之間已更改的文件？
• 還有什麼其他問題應該問，但還沒有想到呢？

在回答的答案：

回覆：http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html這正是我是怎麼做的部署，並且將是一個理想的方法。 Web部署可以正確識別哪些文件已經更改，但是它會超時並且不會發布。解決方案中大約有2500個文件，可能需要很長時間才能確定哪些文件發生了更改？或者可能是發佈具有較短的超時值，並且只需上傳15mb zip文件即可使用。

我確實完全控制了服務器，它支持Web部署。實際上有兩臺服務器：主服務器和一臺備用服務器，以防萬一第一臺服務器出現故障。所以任何解決方案都必須易於部署到多臺服務器上（網絡部署是理想的，直到它停止工作）。

建議爲每個版本創建一個新文件夾，然後將IIS更改爲指向新文件夾，這聽起來像是在發佈過程中會降低停機時間/緩慢時間。但這是一個非常手動的過程，我寧願更自動化的東西。

編輯＃2

我設法縮小它，並發現它的確切位置是緩慢的 - 然而不知其所以然。這是來自部署日誌：

[9/02/2011 12:11:56 a.m.] Performing synchronization pass #1. 
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/1' is applicable to 'iisApp/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope. 
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/2' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope. 
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/2' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope. 
[9/02/2011 12:11:56 a.m.] Parameter entry 'Add write permission to App_Data Folder/1' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data' because of its scope. 
[9/02/2011 12:11:56 a.m.] Source createApp (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True']). Update pending. 
[9/02/2011 12:11:56 a.m.] Update operation on createApp (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) skipped because of rule CreateApplicationRule. 
[9/02/2011 12:11:56 a.m.] Source filePath (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data\Create.sql) does not match destination (Default Web Site/virtual-dir/App_Data\Create.sql) differing in attributes (size['259691','259697'],lastWriteTime['02/08/2011 10:45:20','02/06/2011 03:48:16']). Update pending. 

[400 lines of file updates skipped, time expired 2 seconds ....] 

[9/02/2011 12:11:58 a.m.] Delete operation on filePath (Default Web Site/v2/zzz_app_offline.htm) skipped because of rule DoNotDeleteRule. 
[9/02/2011 12:11:58 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending. 
[9/02/2011 12:11:58 a.m.] Updating setAcl (Default Web Site/virtual-dir/). 
[9/02/2011 12:13:47 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending. 
[9/02/2011 12:13:47 a.m.] Updating setAcl (Default Web Site/virtual-dir/). 
[9/02/2011 12:17:11 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data) does not match destination (Default Web Site/virtual-dir//App_Data) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending. 
[9/02/2011 12:17:11 a.m.] Updating setAcl (Default Web Site/virtual-dir//App_Data). 
[9/02/2011 12:17:11 a.m.] The dependency check 'DependencyCheckInUse' found no issues. 
[9/02/2011 12:17:11 a.m.] The synchronization completed in 1 pass(es). 

緩慢的原因是"Updating setAcl"組件。我正在檢查開發框和服務器框的ACL以查看有什麼不同。但是，將ACL從開發箱複製到服務器箱似乎是一個非常糟糕的主意！我已經在服務器上設置了ACL。

Answer 1

我首先嚐試隔離發生超時的地方。你已經提到了一個有2,500個文件的15MB zip文件，這不會讓我感到特別大。您是否嘗試過在Visual Studio中創建部署包，然後直接在服務器上運行它？這將使網絡延遲超出圖片，這是一個非常基本的變量，當涉及到超時。

至於爲什麼需要上傳整個應用程序的zip文件，您需要記住已更改內容的實際標識以及隨後部署到IIS中的所有操作都發生在服務器上。本地機器上的Visual Studio或msdeploy不是這樣的。

至於爲什麼你不只是手動複製已更改的文件，它在我引用的博客文章中進行了總結，但簡而言之，它很費力且容易出錯。這意味着你需要有意識地完成「我的2,500個文件中的哪些文件剛剛改變」的思考過程，而不是簡單地說「讓我的目標站點與我的開發版本匹配」。你沒有提到你是否發佈了web.config，但是顯然配置轉換是爲什麼簡單的CTRL-C和CTRL-V方法很麻煩的另一個重要原因。

試圖直接從SVN進行更改也是有風險的。您的第一個問題是，如果您要獲得已發佈的適當更改，則需要對要更新的修訂版的完整性和準確性從充滿信心。然後，您將嘗試將這些內容同步到目標上，然後回到前一段中提出的相同問題。另一個大問題是版本控制對象代碼總是令人討厭;您將與項目中的其他人發生永久衝突，並且VCS根本無意以此方式運作。

我的建議是將重點放在解決問題的根本原因 - Web Deploy超時 - 而不是簡單地嘗試解決症狀。隻手動發佈變更或者搞亂IIS綁定只會給您長期帶來更多麻煩，並且會在短期內做更多工作。瞭解如何共享創建包的結果，將其複製到服務器，然後在本地執行，然後我們將從此處執行。一旦按照設計進行工作，您應該看到部署時間不超過幾分鐘，並且在幾秒鐘內就可以測量站點中斷。

順便說一句 - 您可能還想添加您的PC和服務器之間的延遲時間，以及通常需要多長時間通過HTTP傳輸15MB文件。

Answer 2

如果你能控制服務器，一個非常好的選擇是手動上傳壓縮文件。解壓縮，然後使用IIS管理器指向新的代碼庫。這樣停機時間應該是最小的。如果出現問題，您的上一個版本將保持不變，並可以將IIS指向該文件夾。

雖然在共享主機上這不會起作用。也許有一些方法可以通過上傳代碼來適應相同的策略，然後重命名文件夾以使其指向新文件。

無論如何，它似乎web部署應支持只發送更改的內容。但我認爲你的主機需要在這種情況下支持Web部署：http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html

如果你沒有，我想你可以使用腳本來檢測SVN中的修改。下面是關於如何找到已更改的文件的一些信息：http://blog.lysender.com/2010/11/svn-list-modified-files-between-revisions/你必須記住，codefiles被編譯成dll文件，所以我會想象這樣的事情：

1. 發佈的網站（或使用來自statging服務器上的文件不管在你的情況下最有意義）
2. 讓腳本建立一個文件列表來修改（將代碼文件轉換爲它們的dll）
3. 使用可以通過命令行進行控制的ftp推送更改。

Answer 3

一些其他的選擇，你可以考慮：

1）部署到每一次新的目錄，然後使用IIS目錄之間進行切換。

2）爲您的二進制文件使用單獨的Subversion存儲庫。 svn-load-dirs.pl可以將二進制文件加載到subversion中，並可以正確標記已添加，刪除或更改的文件。您可以在自動構建過程結束時運行svn load-dirs。構建過程是唯一檢查此存儲庫的「用戶」，生產服務器是檢查它的唯一位置，因此不存在版本衝突。

部署你只需svn從二進制subversion版本庫更新工作目錄。它以原子方式高效地複製了已更改的文件（即，如果下載失敗，則不會替換任何文件）。如果您在部署後立即發現問題，則可以快速返回到以前的版本。如果你想更新一個aspx文件，你可以在這個文件上做一個有針對性的svn更新。

如果您在服務器上安裝了TortoiseSVN，您還可以立即看到是否有人在沒有經過正確的構建 - >檢入 - >部署路徑的情況下更改了服務器上的任何文件。

唯一需要注意的是，Subversion不處理二進制差異，因此您的存儲庫將快速增長，但如果這種情況永遠成爲問題，您可以簡單地將其擦除並重新開始。

另一個優點是您可以完整記錄您部署的每個版本。

我已經使用這種技術的幾個項目，並希望所有部署系統的工作更喜歡它：即原子更新，便於回滾，有針對性的單個文件更新，完整的版本歷史，...

Answer 4

在構建/開發框中，使用命令行MSBuild構建項目的SLN（或wdproj）。確保預編譯所有內容。在構建之前使用單獨的輸出路徑。獲得壓縮的結果，並將其傳輸到Web服務器的帶外（通過UNC路徑或FTP服務器，或其他）。在服務器上，解壓縮並執行xcopy部署。

爲了減少傳輸時間，使用rsync（也有版本的Windows），或使用7-Zip最大設置壓縮二進制文件。

服務器停機時間最小化，因爲這將是從本地磁盤到本地磁盤複製只。即使速度很快，IIS應用程序池也會回收，爲了彌補這一點，您需要在負載平衡器後面安裝兩臺機器，以便在其他服務器請求時更新一臺機器。 （或許矯枉過正，研究使用IIS的WEB-花園）

要自動化的過程中，使用PowerShell，或者甚至可以簡單地使用批處理文件和PSEXEC運行遠程命令。

Answer 5

@JK從您提供的信息中感覺就像是超時問題。我同意@TroyHunt 15個文件中的2500個文件應該快速部署。特別是在應用ACL時顯示延遲的輸出（無論是否需要更改）。如果是我，我會開始做一些非web部署健康檢查。想到一些想法

• 是域或工作組中的網絡服務器？
• dcdiag顯示什麼？
• netdiag表示什麼？
• 是在相同的域的開發盒和prod框？

是否有機會嘗試應用不再存在的用戶或組，或者是否來自Web服務器域以外的域？您的組織可能擁有包含子域或域信任的域層次結構，這些域有效，但通信在生產數據中心中被阻止。

我想我還要手動看看ACL和看看是否有詞條，不能被解析（它們顯示爲小島嶼發展中國家的決議之前）。

HTH， -Eric

Answer 6

下面是我做的發佈：

1. 我有TeamCity的鉤，每次我做一個使用svn提交它採用了Rake文件將文件複製到一個Dropbox文件夾，我也有一個git倉庫。
2. 對已更改的文件進行提交/推送（對於此git存儲庫）。我還在服務器上安裝了Dropbox
3. 將dropbox（使用git）更改爲登臺應用程序以再次檢查事件。
4. 一旦一切正常，對於舞臺應用程序，我切換它與來自iis的製作一個
5. 當我想再次發佈時，一旦一切都與dropbox同步，我再次拉動上一次製作，現在成爲舞臺的一部分，我再次切換應用程序。

Result->用戶獲得0秒停機時間。

如果你想削減一些角落。您可以直接在生產站點上執行git pull。 Result-> 12秒停機用戶

如果你真的要削減一些角落。您可以將保管箱文件夾直接安裝到您的生產文件夾中，保管箱將同步所有內容。結果5用戶的停機時間爲6秒或更長時間。

Answer 7

事實上，你從VS部署而不是從構建/持續集成服務器部署是這裏的問題。

Answer 8

爲什麼不使用Dropbox？認真....

警告：這並沒有得到測試由我，只是一個假設性回答

解決方案1： 在非專業的方式，我將在所有服務器上安裝的Dropbox包括登臺服務器。而只需從Visual Studio部署到分段。

Dropbox非常快速地同步文件，特別是當您啓用「網絡下載」時，文件從本地服務器下載到Dropbox！

解決方案2： 從Visual Studio創建部署包並將其保存到與dropbox同步的本地文件夾。然後創建一個自動運行deploy.cmd並清空部署文件夾內容的計劃任務，以避免重新部署。

使用Dropbox的

• ACL問題將不會同步:(
• 如投寄箱在托盤（而不是服務）
• 文件夾運行遠程桌面會話應該始終處於激活狀態應該不包含任何被修改的「數據」文件，否則會發生衝突

Answer 9

我剛剛有一個類似的問題，其中webdeploy開始採取很長一段時間，特別是當它達到"Updating setAcl"。我不願意像先前的一些答案所建議的那樣禁用更新ACL，特別是當它能夠很好地將相同的項目部署到不同的服務器時。

所以我研究了兩臺目標機器之間有什麼不同，事後的解決方案非常明顯。在生產機器上，我們有很多臨時的本地文件正在創建和存儲一個月（按設計）。我減少了文件數量，發佈時間從30分鐘縮短到15秒左右。