我一直以来都是使用FTP（有时甚至是xcopy）部署我的Web应用程序，然后手动运行数据库脚本。
我在90年代开始使用这种方式进行部署，但最近，我看到了一些带有安装程序的Web应用程序。我开始质疑，我是否陷入了过时的流程中。我是一名顾问，我的应用程序通常是内部使用的，所以我不必担心分发和其他人的安装。
但我很好奇：是否有人创建安装程序来部署内部的ASP.NET Web应用程序？
如果是这样，为什么？（自愿、强制或作为自动化过程的一部分）
在使用这种方式时，您有遇到任何问题吗？
9个回答
5
当然。我们使用它来制作所有的应用程序。这样，我们创建安装程序并在QA和UAT环境中运行它进行测试，我们知道在生产环境中会发生什么。没有人会猜测某个步骤的顺序，或者是否漏掉了一步。这使得事情变得更容易。
哦，我忘记了自动化流程。我们有系统（Ant Hill Pro）可以自动将其部署到正确的环境中。QA人员不必等待完成某项任务，因为这些任务都在凌晨2点完成。如果他们需要重新运行带有更新的构建，则开发人员检查代码并按下按钮，它会自动部署。不需要等待构建工程师，因为他可能在开会、生病或其他原因。
- Kevin
4
这是一个很好的观点。我首先部署到我们的业务验证服务器，然后从验证服务器复制到生产环境。但这绝对是使用安装程序的一个有效理由。 - John MacIntyre
我从未意识到手动操作有多么痛苦，直到我们开始使用安装程序。不必担心人为因素在测试完成后错过文件或其他问题，这样做会少很多麻烦。 - kemiller2002
“不必担心人为因素”这也是我困扰的问题。我可以问你一个问题吗？你的SQLScript是包含在安装程序中还是分开的？ - John MacIntyre
我认为它不是一个安装程序，而是通过系统运行。该系统将所有脚本编译成一个主脚本，然后针对数据库运行它。我们使所有脚本都可以“重新运行”，在添加等操作之前检查字段是否存在，以便我们可以再次运行脚本。 - kemiller2002
3
您总是希望有一种自动化的方式来构建和部署 - 这大大降低了忘记某个步骤导致的单次错误的几率。此外，它使您能够轻松地将部署转移到其他人身上，而无需教他们100个定制步骤。无论项目是否为内部项目，所有应用程序都应遵循最佳实践。
- Tai Squared
3
“internal or not” 你是在建议即使对于 webhost 也要这样做吗？如果是这样，你如何运行它？你让 webhost 为你运行它吗？ - John MacIntyre
你无法访问你的托管机器吗？如果是这样，那么拥有一个处理所有部署步骤的构建版本就更加重要了，这样你就可以告诉他们只需运行安装程序，而不是复制这些文件、运行这个脚本、勾选这个框等等... - Tai Squared
对于我所做的大多数内部应用程序，我都是这样做的。但是我有两个客户在共享 Web 托管上拥有应用程序。对于这两个客户，我肯定没有权限运行类似的东西...至少我认为我没有...我一直以为我没有。 - John MacIntyre
1
就我个人而言，我有点像楼主；通常我只使用FTP进行部署，但是通常情况下我的应用程序是内部的，或者在其他项目中，完全由我管理。
然而，最近我也开始思考这个问题，并开始考虑如何使用适当的部署方式来改进流程 - 必须记录详细的安装过程可能会非常痛苦。
- CapBBeard
1
是的，这种方法的一个大问题是，在整个过程中应用程序都会崩溃，手动操作可能需要几分钟，并且需要观察每一步。 - John MacIntyre
1
我使用Powershell，发现自动化许多任务非常容易。起初可能会有些不同，但最终你会发现这一切都是关于.NET库的强大力量！！！
- Andre
2
所以你有一个 PowerShell 脚本来自动化安装？这也是一个有趣的想法。谢谢。 - John MacIntyre
是的，John，我记得我在这些脚本上执行的操作有：1.备份最新版本
2.删除不必要的文件
3.配置web.config
4.获取所有.js文件并将它们压缩
5.ZIP和FTP之后，我会运行另一个脚本来实际安装网站到目标服务器上。 - Andre Gallo
1
我使用“Web Setup Project”创建了一个MSI，用于安装“Web Deployment Project”的输出结果，以供内部应用程序使用。我们的服务器管理员无法完成50个步骤的手动安装任务。对于我的当前应用程序，我的服务器管理员不喜欢MSI安装程序的“黑匣子”感觉，而更喜欢获得一堆文件和一个50个步骤的部署手册。（看到模式了吗？问问你的服务器管理员他想要什么。）
“Web Setup Project”并没有立即明显地显示如何安装到除“默认网站”之外的任何其他位置，但它使安装过程可重复，并创建了一种内置的回滚方式（只需从上一个版本运行安装程序即可）。
当然，这假设您的虚拟目录不包含任何用户修改的内容——我不会相信MSI能够正确合并用户创建的和新文件。
“Web Setup Project”并没有立即明显地显示如何安装到除“默认网站”之外的任何其他位置，但它使安装过程可重复，并创建了一种内置的回滚方式（只需从上一个版本运行安装程序即可）。
当然，这假设您的虚拟目录不包含任何用户修改的内容——我不会相信MSI能够正确合并用户创建的和新文件。
- MatthewMartin
1
“MSI安装程序的‘黑盒子’感觉” 我完全能理解。 - John MacIntyre
1
我们在这里使用“XCopy”部署模型，因为运维人员有自己的方法在服务器上设置新 Web 应用程序的安全性。但是，当我们需要安装一个使用较新版本 Crystal Reports 的 Web 应用程序时，我们确实需要使用安装程序，因为它需要对密钥进行特殊处理，而服务器本身没有完整的 CR 版本。因此，在处理第三方应用程序时，请记住它们可能需要执行某种合并模块，MSI 可以轻松处理该操作。
- Dillie-O
2
当你执行xcopy操作时，你只是单独运行SQL脚本吗？还是有其他的流程？ - John MacIntyre
是的，应该也加上那个。通常我会告诉数据库管理员应用程序已准备就绪，他们会进行数据库迁移，然后我会通知运维人员，然后他们会创建IIS站点并复制文件。 - Dillie-O
1
是的...我们有一个应用程序需要设置很多先决条件...Web服务、Windows服务、用户帐户、安全性、文件夹创建、GAC位等等...我将它们全部打包成一个漂亮的MSI，带有自定义操作，可以干净地安装和卸载。在新的盒子上部署节省了大约一小时的工作时间。
许多其他较小的应用程序只需通过发布网站到本地文件夹，然后将内容ftp到目标即可部署。
- Kev
1
这在很大程度上取决于您的项目规模、环境和内部用户群。我很少使用msi进行部署，因为我们的操作规模太小，没有多个环境（除了SharePoint，那是完全不同的）。我们使用VS开发并部署Web应用程序到开发框中，如果被批准，则再次使用VS将其部署到生产框中。
唯一的条件是我们有多个web.config副本（附加了测试、开发和生产），然后根据部署位置删除相应文件的后缀。
这可能不是最佳方法（我知道它不是），但它有效地促进了在小型用户环境中快速部署小到中等规模的解决方案。
- Charlie
2
谢谢你的回答，但我认为你永远不会太小而无法使用多环境设置。这也不难或昂贵，特别是使用虚拟机。 - John MacIntyre
这取决于你是否是一个资源已经被拉满的人。谁将设置这些环境？维护它们？更重要的是，一旦测试环境建立起来，谁将在测试环境上测试代码？很容易就能提出你的论点。如果你有机会进行这样的设置，那当然更好了！但由于我已经超负荷了，而且没有其他人可以做这件事，所以我无法做到。 - Charlie
0
F5ToDebug...
你是说如果没有时间做好，就可以走捷径吗？
“谁会在测试环境中测试代码？” 你自己说过你有配置文件用于测试 - 那为什么不是一个合适的测试呢？
- Pete
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接