用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秒左右。