你使用什么方法将ASP.Net应用程序部署到生产环境？

Question

你使用什么方法将ASP.Net应用程序部署到生产环境？

19

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

现在我正在评估我们的部署方法，特别关注内置的部署工具；具体而言，我正在查看自定义安装任务，并尽可能多地使用标准安装程序功能（主要是用户界面）。

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

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

- Hooloovoo

1

自从我发布了这个原始问题以后，我发现了WiX。它是开源的，而且免费。Microsoft也用它来开发Office 2007的部署包。一旦你理解了基本原理，它似乎很容易使用，而且界面允许你在安装时选择和挑选组件。 - Hooloovoo

仅供更新；应用程序发布自动化工具是专门为此目的设计的，有许多值得注意的工具可以查看比较https://en.wikipedia.org/wiki/Application_release_automation。 - Karl Harnagy

6个回答

0

我所做的一些事情如下：

1）使用Web部署项目编译和清理构建，以及在配置更改时处理web.config部分替换，以便在不同环境之间进行切换。

2）使用NAnt以重复的方式完成所有构建、归档和复制工作。

Web部署项目最终会创建一个MSBuild文件，可以用来代替NAnt；然而，我来自Java背景，并且一直使用Ant，因此NAnt是我在.Net中的首选。如果添加NAnt Contrib任务，您将能够部署文件并处理源代码控制（如果它不是默认任务的一部分）和Sql脚本执行更改等项。

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

希望这可以帮助到您。

- JamesEggers

目前我们使用JetBrains的TeamCity，而且我让其他人设置构建脚本！这相当简单，并且我们在CI服务器上使用MSBuild。我还使用Web部署项目来正确构建网站，但有时设置它可能有些棘手。 - Hooloovoo

我明白你的意思，需要正确设置构建。我最终选择为每个部署环境设置一个配置管理器环境，然后使用Web部署项目在每个环境下进行构建（使用NAnt或CI服务器的构建文件进行自动化）。如果需要进行其他清理/操作，我要么直接编辑WDproj（msbuild）文件，要么在NAnt中进行更新。由于你不编写TeamCity的CI构建文件，wdproj将是最好的选择。除此之外，看看每个环境的痛点，并专注于解决这些问题。 - JamesEggers

0

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

团队基础构建每晚运行以重新构建解决方案并将所有内容复制到“发布CD”目录中，任何人都可以访问并测试最新的“发布”。

老实说，像我们这样的小团队使用TFS构建有点过头了，我只是因为习惯才使用它。

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

- simon831

0

1) 使用MSBUILD构建项目

2) 将文件FTP到生产环境

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

- Ken Burkhardt

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

0

对于内部网站，我们使用CruiseControl与SVN结合使用，自动重建网站。

理论上，如果您可以远程映射驱动器到客户的内部网，您可以将此模型扩展到VPN上。或者更快速和简单的解决方案可能是使用类似SyncBack的工具来同步包含网站编译后的DLL的远程文件夹。

- Darth Continent

-2

使用复制 Web 工具部署 Web 应用程序

《微软培训套件书籍：基于 Web 的开发》中的文本

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

- Muhammad Akhtar

我经常使用的环境分布在5个专用的Web服务器上。我们正在寻找可重复且易于部署的路径，特别是因为我们无法访问发布或生产环境（部署路径中的第4和第5个环境）。所以基本上，我们正在向许多用户部署。 :-) - Hooloovoo

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Steve J · Accepted Answer

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

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

Cruise Control 配置了连续集成构建，代码检入后会运行。它也配置了独立的开发、QA、Stage和Production任务。

要部署到开发环境，必须首先从 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”文件。

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

谢谢！