使用Web Deploy发布ASP.NET MVC2站点 [英] Publishing an ASP.NET MVC2 site with Web Deploy
问题描述
我目前使用Web Deploy， http://learn.iis.net /page.aspx/346/web-deploy/ 发布我的MVC2应用程序。它过去工作得很好，但现在已经到了不能继续使用它的地步：
当MVC应用程序很小，只有少数用户很容易发表。右键单击Visual Studio中的项目，然后选择发布。而且因为只有少数用户，很容易找到一个没有人使用该网站进行快速更新的时间。
然后应用程序变大了，再多一些用户。 发布动作开始时间越来越长，偶尔超时。即使我在部署之前回收了应用程序池，仍然需要很长时间。
当没有人使用该网站时，更难找到一个时间，因此更新可能会在不影响任何人的情况下完成。
然后，发布操作每一次都开始超时，我不得不根据以前的未回答的问题切换到手动部署：一个href =http://stackoverflow.com/questions/4133485/visual-studio-2010-web-deploy-times-out-what-to-do> Visual Studio 2010 - Web部署超时 - 该怎么办？
现在，手动部署需要更长的时间，从5到20分钟。而且用户数量显着增长，所以部署总是影响某人（响应时间慢，超时，站点不可用等）
那么我该怎么办？有没有更好的选择使用Web部署？
编辑：
今天的部署需要18分钟才能发布49个更改的文件。情况是荒谬的，现在是我们网站最大的弱点之一。所以我开始一个体面的大小的赏金，希望解决这个问题。
还有一些可能导致解决方案的问题：
- 为什么只有几个文件被更改了需要很长时间？
- 为什么Web部署zip总是包含整个代码库而不只是更改文件？
- 为什么我不自己手动复制更改的文件，并跳过整个Web部署？但是很难手动确定哪些文件已经更改。我使用SVN - 它是否只能输出两个分支之间发生变化的文件？
- 还有什么其他问题，但还没有想到？
回复答案：
Re： 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.]执行同步传递＃1。
[9/02/2011 12:11:56 am]参数条目'IIS Web应用程序名称/ 1'适用于'iisApp / C：\src\Site.2010\Site.UI\ obj\Release\Package\PackageTmp因为它的范围。
[9/02/2011 12:11:56 am]参数条目'IIS Web应用程序名称/ 2'适用于'setAcl / C：\src\Site.2010\Site.UI\ obj\Release\Package\PackageTmp因为它的范围。
[9/02/2011 12:11:56 am]参数条目'IIS Web应用程序名称/ 2'适用于'setAcl / C：\src\Site.2010\Site.UI\ obj\Release\Package\PackageTmp因为它的范围。
[9/02/2011 12:11:56 am]参数条目向App_Data文件夹/ 1添加写入权限适用于'setAcl / C：\src\Site.2010\Site.UI \obj\Release\Package\PackageTmp\App_Data因为它的范围。
[9/02/2011 12:11:56 am]源createApp（C：\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp）不匹配目标（默认网站/ virtual-dir /）属性不同（isDest ['False'，'True']）。更新待定。
[9/02/2011 12:11:56 am] createApp上的更新操作（C：\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp）由于规则CreateApplicationRule而跳过。
[9/02/2011 12:11:56 am]源filePath（C：\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data \Create.sql）与属性不同的目标（默认网站/ virtual-dir / App_Data\Create.sql）不匹配（size ['259691'，'259697']，lastWriteTime ['02 / 08/2011 10 ：45：20'，'02/06/2011 03:48:16']）。更新待定。
[400行文件更新跳过，时间过期2秒....]
[9/02/2011 12:11:58 am]删除filePath上的操作（默认网站/ v2 / zzz_app_offline.htm）由于规则DoNotDeleteRule而被跳过。
[9/02/2011 12:11:58 am]源setAcl（C：\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp）不属性不同的匹配目标（默认网站/ virtual-dir /）（isDest ['False'，'True']，setAclUser，setAclAccess）。更新待定。
[9/02/2011 12:11:58 a.m.]更新setAcl（默认网站/ virtual-dir /）。
[9/02/2011 12:13:47 am]源代码setAcl（C：\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp）不属性（isDest ['False'，'True']，setAclUser，setAclAccess）的匹配目标（默认网站/ virtual-dir /））。更新待定。
[9/02/2011 12:13:47 a.m.]更新setAcl（默认网站/ virtual-dir /）。
[9/02/2011 12:17:11 am]源setAcl（C：\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data ）与属性不同的目标（默认网站/虚拟目录// App_Data）不匹配（isDest ['False'，'True']，setAclUser，setAclAccess）。更新待定。
[9/02/2011 12:17:11 a.m.]更新setAcl（默认网站/ virtual-dir // App_Data）。
[9/02/2011 12:17:11 a.m.]依赖关系检查'DependencyCheckInUse'没有发现任何问题。
[9/02/2011 12:17:11 a.m.]同步在1遍（es）完成。
缓慢的原因是更新setAcl组件。我正在检查开发框和服务器框的ACL，看看有什么不同。然而，将ACL从一个开发框复制到一个服务器盒子似乎是一个非常糟糕的主意！我已经在服务器上设置好了ACL。
我将首先尝试隔离超时发生的地方。你提到了一个15MB的压缩文件，2500个文件，这不会使我特别大。您是否尝试在Visual Studio中创建一个部署包，然后直接在服务器上运行？这将使网络延迟超出图片，这是一个非常基本的变数，当涉及到超时。
至于为什么整个应用程序的zip需要上传，您需要记住实际的身份识别已经发生了变化，后来部署到IIS中都发生在服务器上。你的本地机器上的Visual Studio或者msdeploy不是在这个机器上打电话的。
至于为什么你不只是手动复制更改的文件，你引用的博客文章，但简而言之，它是费力和容易出错的。这意味着你需要自觉地通过我的2500个文件刚刚改变的思想过程，而不是简单地说让我的目标网站符合我的开发版本。你没有提到是否发布web.config，但是显然配置转换是简单的CTRL-C然后CTRL-V方法麻烦的另一个重要原因。
试图直接从SVN进行更改也是有风险的。您的第一个问题是，如果您要获得相应的更改发布，您需要完全信任您正在从更新的修订版本的完整性和准确性。然后，您尝试将其同步到目标，并返回上一段中提出的相同问题。另一个大问题是版本控制对象代码总是讨厌;您将处于与项目中任何其他人的永久性冲突状态，VCS根本不打算以这种方式运行。
我的建议是专注于解决问题的根本原因 - Web部署是超时的 - 而不是简单地尝试解决症状。仅手动发布更改或使用IIS绑定进行操作只会为您带来更多麻烦，从长远来看，还有更多的工作在短期内。看看你如何分享创建包的结果，将其复制到服务器，然后在本地执行，我们将从那里拿走。一旦你按照设计工作，你应该看到的部署时间不超过几分钟，站点中断测量在几秒钟内。
BTW - 你可能还想添加什么您的PC和服务器之间的延迟，以及通过HTTP传输15MB文件通常需要多长时间。
I currently use Web Deploy, http://learn.iis.net/page.aspx/346/web-deploy/ to publish my MVC2 app. It used to work well, but now it is got to the point where I can't continue using it:
When the MVC app was small and had only a few users it was easy to publish. Just right click the project in Visual Studio and choose "Publish". And because there were only a few users it was easy to find a time when no one was using the site to do a quick update.
Then the app got bigger and had a few more users. The "Publish" action started taking longer and longer and occasionally timing out. Even when I recycled the app pool before deploy it still took a long time.
Also it became harder to find a time when no one was using the site so the update could be done without affecting anyone.
Then the "Publish" action started timing out every single time, and I had to switch to manual deployment as per this earlier unanswered question: Visual Studio 2010 - web deploy times out - what to do?
Now the manual deploy is taking longer and longer, from 5 to 20 minutes. And the number of users has grown significantly, so the deployment always affects someone (slow response times, timeouts, site unavailable, etc)
So what can I do? Is there a better alternative to using web deploy?
Edit:
Today's deployment took 18 minutes to publish just 49 changed files. The situation is just ridiculous and is one of the biggest weaknesses of our site right now. So I'm starting a decent sized bounty in the hopes of solving this.
Some more questions that may lead to a solution:
- Why would it take so long when only a few files have been changed?
- Why does the web deploy zip always include the entire codebase and not just changed files?
- Why don't I just manually copy the changed files myself and skip the whole web deploy? But it is hard to manually work out what files have changed. I use SVN - does it have a way to output only files that have changed between two branches?
- What other questions should I be asking but haven't thought of yet?
In reply to answers:
Re: http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html This is exactly how I was doing the deploy, and would be an ideal method. Web deploy does correctly identify which files have changed, however it times out and no publish occurs. There are around 2500 files in the solution, perhaps it is taking too long to identify which ones are changed? Or it could be that publish has a short timeout value and that just uploading the 15mb zip file uses all that time up.
I do have full control over the server, and it does support web deploy. There are actually 2 servers: the primary live server, and a redundant server that we keep ready in case the first falls over. So any solution has to be easy to deploy to more than one server (web deploy was ideal until it stopped working).
The suggestion of creating a new folder for each release and then just changing IIS to point to that new folder sounds like it will result in lower downtime/slowtime when during the publish. But it is a very manual process and I would prefer something more automated.
Edit #2
I have managed to narrow it down, and found exactly where it is slow - but not why. This is from the deploy log:
[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).
The cause of the slowness is the "Updating setAcl" component. I am examining the ACLs of the development box and server box to see what is different. However it seems like an extremely bad idea to copy the ACL from a dev box to a server box! I already had the ACL set up just fine on the server.
I'd start by trying to isolate where the timeout is happening. You've mentioned a 15MB zip with 2,500 files which doesn't strike me as particularly large. Have you tried creating a deployment package in Visual Studio then running it directly on the server? This will take network latency out of the picture which is a pretty fundamental variable when it comes to timeouts.
As for why a zip with the entire application needs to be uploaded, you need to remember the actual identification of what has changed and subsequent deployment into IIS all happens on the server. It's not Visual Studio or msdeploy on your local machine calling the shots on this.
As for why you don't just manually copy the changed files over, it's summarised in my blog post you've referenced but in short, it's laborious and error prone. It means you need to consciously work through the thought process of "which of my 2,500 files just changed" rather than simply saying "make my target site match my development version". You haven't mentioned if you're publishing the web.config or not but obviously config transforms is another important reason why the simple CTRL-C then CTRL-V approach is cumbersome.
Trying to just take a change directly from SVN is also risky. Your first problem is you need to have complete confidence in the integrity and accuracy of the revision you're updating from if you're to get the appropriate changes published. You're then left with trying to sync these to the target and you're back at the same issues raised in the previous paragraph. The other big problem is versioning object code is always nasty; you'll be in a perpetual state of conflict with anyone else on the project and VCS is simply not intended to function this way.
My advice would be to focus on solving the root cause of the problem - Web Deploy is timing out - rather than simply trying to work around the symptoms. Manually publishing changes only or messing around with IIS bindings is only going to create more trouble for you in the long run and a lot more work in the immediate term. See how you go sharing the results of creating a package, copying it to the server then executing it locally and we'll take it from there. Once you have it working as designed, you should be seeing deployments no more than a few minutes and site outage measured in seconds.
BTW - You might also like to add what sort of latency you have between your PC and the server and how long it would normally take to transfer a 15MB file over HTTP.
这篇关于使用Web Deploy发布ASP.NET MVC2站点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
