当MVC应用程序很小，只有少数用户很容易发布。右键单击Visual Studio中的项目并选择“发布”。而且由于只有少数用户，很容易找到一个没有人使用该网站进行快速更新的时间。
那么应用程序越来越大，还有更多的用户。 “发布”动作开始时间越来越长，偶尔超时。即使在部署之前我再次使用应用程序池，仍然需要很长时间。
此外，当没有人使用该网站时，更难找到一个时间，所以更新可以在不影响任何人的情况下完成。
然后，“发布”操作每次都会开始超时，我不得不根据以前的未回答的问题切换到手动部署：Visual Studio 2010 – web deploy times out – what to do?
现在手动部署需要更长的时间，从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.] 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',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',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).
缓慢的原因是“更新setAcl”组件。我正在检查开发框和服务器框的ACL，看看有什么不同。然而，将ACL从一个开发框复制到一个服务器盒子似乎是一个非常糟糕的主意！我已经在服务器上设置好了ACL。
解决方法
至于为什么需要上传整个应用程序的zip，您需要记住在IIS中所发生的更改和后续部署的实际标识都发生在服务器上。您的本地机器上不是Visual Studio或msdeploy，可以调用这个镜头。
至于为什么你不只是手动复制更改的文件，它总结在我引用的博客文章中，但简言之，它是费力和容易出错的。这意味着你需要自觉地通过“我的2500个文件刚刚改变”的思想过程，而不是简单地说“让我的目标网站符合我的开发版本”。你没有提到是否要发布web.config，但是显然配置转换是为什么简单的CTRL-C然后CTRL-V方法是麻烦的另一个重要原因。
试图直接从SVN进行更改也是有风险的。您的第一个问题是，如果您要发布适当的更改，您需要对您正在更新的修订版的完整性和准确性有完全的信心。然后，您尝试将其同步到目标，并返回上一段中提出的相同问题。另一个大问题是版本控制对象代码总是讨厌;您将与项目中的任何其他人处于永久的冲突状态，VCS根本不是以这种方式运行。
我的建议是专注于解决问题的根本原因 – Web部署是超时的 – 而不是简单地试图解决症状。仅手动发布更改或使用IIS绑定进行操作只会为您带来更多麻烦，从长远来看，还有更多的工作在短期内。看看你如何分享创建包的结果，将其复制到服务器，然后在本地执行，我们将从那里拿走。一旦你按照设计工作，你应该看到部署不超过几分钟，站点停电在几秒钟内测量。
