使用 Web Deploy 發布 ASP.NET MVC2 站點
我目前使用 Web Deploy，http : //learn.iis.net/page.aspx/346/web-deploy/ 來發布我的 MVC2 應用程序。它曾經執行良好，但現在它已經到了我無法繼續使用它的地步：
當 MVC 應用程序很小並且只有少數使用者時，它很容易發布。只需右鍵點擊 Visual Studio 中的項目並選擇“發布”。而且因為只有少數使用者，所以很容易找到沒有人使用該網站進行快速更新的時間。
然後該應用程序變得更大，並擁有更多使用者。“發布”操作開始花費越來越長的時間，並且有時會超時。即使我在部署之前回收了應用程序池，它仍然需要很長時間。
此外，很難找到沒有人使用該網站的時間，因此可以在不影響任何人的情況下完成更新。
然後“發布”操作每次都開始超時，我不得不根據之前未回答的問題切換到手動部署：Visual Studio 2010 - Web 部署超時 - 怎麼辦？
現在手動部署花費的時間越來越長，從 5 到 20 分鐘。並且使用者數量顯著增長，因此部署總是會影響某人（響應時間慢、超時、站點不可用等）
那麼我能做什麼呢？有沒有比使用 web deploy 更好的選擇？
編輯：
今天的部署僅用了 18 分鐘就發布了 49 個更改的文件。這種情況很荒謬，是我們網站目前最大的弱點之一。所以我開始了一個體面的賞金，希望能解決這個問題。
還有一些可能會導致解決方案的問題：
- 為什麼只更改了幾個文件需要這麼長時間？
- 為什麼 web deploy zip 總是包含整個程式碼庫而不僅僅是更改的文件？
- 為什麼我不自己手動複製更改的文件並跳過整個 Web 部署？但是很難手動計算出哪些文件發生了變化。我使用 SVN - 它有沒有辦法只輸出在兩個分支之間發生變化的文件？
- 我還應該問哪些其他問題，但還沒有想到？
回复答案：
回复：http ://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html這正是我進行部署的方式，並且將是一種理想的方法。Web 部署確實可以正確辨識哪些文件已更改，但它會超時並且不會發生髮布。解決方案中有大約 2500 個文件，可能需要很長時間才能確定哪些文件已更改？或者可能是發布的超時值很短，並且僅上傳 15mb 的 zip 文件就使用了所有的時間。
我確實可以完全控制伺服器，並且它確實支持 Web 部署。實際上有 2 台伺服器：主要的實時伺服器，以及我們隨時準備的冗餘伺服器，以防第一台伺服器出現故障。因此，任何解決方案都必須易於部署到多個伺服器（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。
我會首先嘗試隔離發生超時的位置。您提到了一個包含 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 文件通常需要多長時間。
@JK 從您提供的資訊來看，感覺像是超時問題。我同意@TroyHunt 15 兆中的 2500 個文件應該快速部署。特別是在應用 ACL 時顯示延遲的輸出（無論是否需要更改）。如果是我，我會開始做一些非網路部署的健康檢查。一些想法浮現在腦海
- 網路伺服器在域或工作組中嗎？
- 顯示什麼
dcdiag？- 顯示什麼
netdiag？- 開發盒和產品盒在同一個域中嗎？
您是否有機會嘗試應用不再存在、已禁用或來自 Web 伺服器域以外的域的使用者或組？您的組織可能具有包含子域或域信任的域層次結構，它們是有效的，但生產數據中心中的通信被阻止。
我想我也會手動查看 ACL，看看是否有無法解析的條目（它們在解析之前顯示為 SIDS）。
HTH，-埃里克