您使用什么方法将 ASP.Net 应用程序部署到野外？答案

【问题标题】：What method do you use to deploy ASP.Net applications to the wild?您使用什么方法将 ASP.Net 应用程序部署到野外？
【发布时间】：2010-11-01 18:24:43
【问题描述】：

目前，我们通过在本地发布网站并将 zip 文件与（通常）冗长的部署说明通过电子邮件发送给系统管理员来部署已编译的 ASP.Net 应用程序。这是因为我们第一次向客户部署 ASP.Net 应用程序时，开发和测试 IIS 实例是相同的，我们无法将该站点两次部署到同一台机器上。这为所有后续项目的部署奠定了基调。

我现在正在评估我们的部署方法，并专门研究内置的部署工具；具体来说，我正在研究自定义安装任务并尽可能多地使用标准安装程序功能（主要是用户界面）。

其次，我正在考虑合并部署和自动更新。

您如何在您的组织中部署软件？您使用什么工具，最常遇到什么问题？

【问题讨论】：

自从我发布这个原始问题以来，我发现了 WiX。它是开源的，而且是免费的。它也是微软用来开发 Office 2007 部署包的工具。一旦您了解了基础知识，它似乎很容易使用，并且界面允许您在安装时挑选和选择组件。
只是一个更新；应用程序发布自动化工具是专门为此目的设计的，有很多值得注意的工具可供比较en.wikipedia.org/wiki/Application_release_automation

标签： asp.net deployment wix

【解决方案1】：

我们有专用的 DEV、TEST、STAGE 和 PRODUCTION 服务器。

我们还有一台运行 Cruise Control 的专用构建机器。

Cruise Control 配置用于持续集成构建，该构建在签入代码后运行。它还配置用于单独的开发、QA、阶段和生产任务。

要部署到开发，首先从 SVN 中检索代码并构建，然后将“Precompiled Web”文件夹复制到开发网站，并将 Web 服务项目复制到开发应用程序服务器。 Cruise Control 还配置为在构建开始之前“标记”源代码，以便我们可以在以后重现构建，或者如果我们需要进行热修复，则从标记分支。

为了部署到 QA，文件从开发机器复制到 QA 机器。

同样，为了部署到 Stage，文件从 QA 机器复制到 Stage 机器。

最后，为了部署到生产环境，文件再次从 Stage 机器复制到 Production 机器。

为了配置每个环境，我们有一个自定义工具，它是每个环境的 Cruise Control 任务的一部分，用于修改连接字符串、“debug=true|false”、“customErrors=Off|RemoteOnly”和其他特定于环境的设置。

因此，每个环境都可以通过 Cruise Control 仪表板中的按钮进行部署。

需要注意的是，我们目前在 Cruise Control 配置文件中配置了生产数据库密码...如果将它移到其他地方会很好！

最后，让我补充一点，即使我们的生产机器位于专用托管设施中，服务器也可以从我们的 Cruise Control 机器访问，这使得进行生产部署变得非常容易。唯一的手动步骤是加密 web.config 文件并删除 Cruise Control 放置的“AppOffline.html”文件。

如果这有帮助，或者如果您有任何问题，请告诉我。

谢谢！

【讨论】：

如何从 CC 机器访问托管设施中的生产机器？（UNC、FTP 等）？
不知何故，生产机器可以在本地网络上使用，但只能从某些机器上使用（巡航控制机器就是其中之一）。我不再在那家公司，所以我不再可以直接访问系统管理员来询问。因此，部署就像只是将文件复制到网络上的另一台机器一样。我相信使用了 UNC 路径。

【解决方案2】：

我做了以下几件事：

1) 使用 Web 部署项目来编译和清理构建，并在配置在环境之间发生更改时处理 web.config 部分替换。 2) 使用 NAnt 以重复的方式完成所有的构建、归档和复制。

Web 部署项目最终会创建一个 MSBuild 文件，该文件可用于代替 NAnt；但是，我来自 Java 背景并一直使用 Ant，所以 NAnt 是我在 .Net 中的首选。如果您添加了 NAnt Contrib 任务，您不仅可以部署文件，还可以处理诸如源代码控制（如果它不是默认任务的一部分）和用于更改的 Sql Script Execution 等项目。

目前我同时使用这两个选项。我有我的 NAnt 构建文件通过 MSBuild 调用 Web 部署项目。通过为每个环境设置配置管理器，它允许我自动管理 web.config 部分的替换，并且仍然可以相当不错地控制我的版本的复制和存档。

希望这会有所帮助。

【讨论】：

目前我们使用 JetBrains 的 TeamCity，我让其他人设置构建脚本！这相当简单，我们在 CI 服务器上使用 MSBuild。我还使用 Web 部署项目来正确构建站点，但有时要正确设置它可能有点繁琐。
我知道您在正确获取构建设置方面的意思。我最终默认为我拥有的每个部署环境设置一个配置管理器环境，然后我们在每个环境下构建 Web 部署项目（使用 NAnt 或 CI 服务器的构建文件自动执行）。如果需要额外的清理/操作，我将直接编辑 WDproj (msbuild) 文件或在 NAnt 中进行更新。由于您不为 TeamCity 编写 CI 构建文件，因此 wdproj 将是您的最佳选择。除此之外，请查看每个环境的痛点并专注于这些痛点。

【解决方案3】：

我们使用 web 部署项目和 VS 2008 项目从 webdeployment 和其他项目的输出创建一个 .msi。一个名为“设置”的普通 Windows 应用程序用于执行大量数据库创建和初步工作，而不是尝试使用自定义步骤自定义设置项目。自己做这件事比尝试自定义 MS 代码要容易得多。然后，此 Windows 应用程序调用用户需要的正确 .msi 文件。

团队基础构建每天晚上运行以重建解决方案并将所有内容复制到“发布 CD”目录中，任何人都可以访问该目录并在最新的“版本”上进行测试。老实说，TFS 构建对于像我们这样的小团队来说有点过火了，我只使用它是因为它是我习惯的。

在以前的公司中，我们使用了这个http://www.finalbuilder.com/，我可以推荐它，因为它易于使用和支持的软件数量。

【讨论】：

【解决方案4】：

1) 使用 MSBUILD 构建项目

2) FTP 文件到生产环境

3) 手动复制/粘贴到每个网络服务器

【讨论】：

这样做的问题是我们无法访问第三个环境，因此我们需要尽可能地自动化。从企业品牌的角度来看，这也不是很强大。话虽如此，这几乎就是我们过去几年一直在做的事情！

【解决方案5】：

对于 Intranet 站点，我们将 CruiseControl 与 SVN 结合使用以自动重建站点。

理论上，如果您可以将驱动器远程映射到客户端的 Intranet，则可以通过 VPN 扩展此模型。或者更快速和更肮脏的解决方案可能是使用像 SyncBack 这样的工具来同步包含站点已编译 DLL 的远程文件夹。

【讨论】：

【解决方案6】：

使用复制 Web 工具部署 Web 应用程序
Microsoft Training Kit Book 中的文本基于 Web 的开发
如果您要向许多用户提供 Web 应用程序（例如，允许人们从 Web 下载应用程序并安装它），那么 Web 安装项目很有用。如果您负责为您的组织更新特定网站，那么每次进行更新时登录到 Web 服务器并安装 Windows Installer 程序包是不切实际的。对于内部应用程序，您可以直接在 Web 服务器上编辑 Web 应用程序。但是，您所做的更改会立即在您的生产 Web 应用程序中实现，这包括可能存在的任何错误。为了使自己能够测试 Web 应用程序，您可以在计算机上编辑 Web 应用程序的本地副本，并使用 Copy Web 工具将更改发布到生产 Web 服务器。您还可以使用复制 Web 工具将更改从登台服务器发布到生产 Web 服务器，或在任何两个 Web 服务器之间发布。复制 Web 工具可以将单个文件或整个网站复制到源网站和远程网站或从源网站和远程网站复制。您还可以选择同步文件，这涉及仅复制更改的文件并检测可能的版本冲突，其中源站点和远程站点上的同一文件已被单独编辑。 Copy Web 工具不能合并单个文件中的更改；只能复制完整的文件。

【讨论】：

我最常使用的环境分布在 5 个专用 Web 服务器上。我们正在寻找一种可重复且简单的部署路径，特别是当我们无法访问发布或生产环境（部署路径中的环境 4 和 5）时，所以基本上，我们正在部署到许多用户。 :-)