我总是通过 FTP（有时甚至是 xcopy）部署我的 Web 应用程序，然后自己手动运行数据库脚本。
我在 90 年代开始以这种方式进行部署，但最近，我看到了一些带有安装程序的 Web 应用程序。我开始质疑，如果我被锁定在一个过时的过程中。我是一名顾问，我的应用程序通常是内部的，所以我不担心分发和让其他人安装它们。
但我很好奇；有人创建安装程序来部署内部 asp.net Web 应用程序吗？
如果是这样，为什么？ （自愿、强制或自动化过程的一部分）
你这样做有什么问题吗？
【问题讨论】：
标签： asp.net deployment installation release-management
绝对。我们用它来做我们所有的应用程序。这样，我们创建安装程序并在 qa 和 uat 环境中运行它以进行测试，我们确切地知道生产中会发生什么。没有人猜测某人可能会按照什么顺序做某事，或者他们是否错过了一步。它使事情变得容易得多。
哦，我也忘记了自动化过程。我们有适当的系统（Ant Hill Pro），可以自动将其部署到适当的环境中。质量检查人员不必等待完成某件事，因为这一切都在凌晨 2 点完成。如果他们需要使用更新重新运行构建，开发人员会签入代码，我们按下一个按钮，它就会自动部署。无需等待构建工程师，因为他正在开会或生病或其他任何事情。
【讨论】：
您总是希望有一种自动化的方式来构建和部署 - 如果您忘记了某个步骤，它会大大减少一次性错误的机会。此外，它还允许您轻松地将部署卸载给其他人，而无需教他们 100 个自定义步骤。无论项目是否为内部项目，所有应用程序都应遵循最佳实践。
【讨论】：
我个人有点像 OP；通常我只是使用 FTP 进行部署，但通常我的应用程序是内部的，或者在其他项目的情况下，100% 由我管理。
不过，我最近也一直在考虑这个问题，并开始考虑如何使用正确的部署来改进流程 - 必须记录详细的安装过程可能会很痛苦。
【讨论】：
我使用Powershell 并发现自动执行许多任务非常容易。一开始你可能会发现有点不同，但最后你会发现这完全取决于 .NET 库的强大功能！！！
【讨论】：
我已使用“Web Setup Project”创建了一个 MSI，该 MSI 为内部应用安装了“Web Deployment Project”的输出。我们的服务器管理员无法完成 50 步手动安装的任务。对于我当前的应用程序，我的服务器管理员不喜欢 MSI 安装程序的“黑匣子”感觉，更喜欢获取一堆文件和 50 步部署手册。 （在这里看到一个模式？问问你的服务器管理员他想要什么。）
Web 安装项目并没有立即明确如何安装到“默认网站”以外的任何地方，除此之外，它使安装过程可重复并创建了一种内置的回滚方式（只需运行1 版本前的安装程序）。
这当然假设您的虚拟目录不包含任何用户修改的内容——我不相信 MSI 可以正确合并用户创建的文件和新文件。
【讨论】：
我们在这里使用“XCopy”部署模型，因为 Ops 人员有自己的方法在服务器上的新 Web 应用程序上设置安全性。
但是，当我们必须安装使用较新版本 Crystal Reports 的 Web 应用程序时，我们确实需要使用安装程序，因为它必须使用密钥执行一些特殊操作，而且我们没有完整版本的服务器本身的 CR。因此，在使用第三方应用程序时请记住这一点，他们可能需要执行某种 MSI 可以轻松处理的合并模块。
【讨论】：
是的……我们有一个需要设置很多先决条件的应用程序……Web 服务、Windows 服务、用户帐户、安全性、文件夹创建、GAC 位等……我全部完成了通过可以干净地安装和卸载的自定义操作进入一个不错的 MSI。在新机器上部署时节省了大约一小时的工作时间。
许多其他较小的应用程序只是通过将网站发布到本地文件夹然后将内容通过 ftp 传输到目标来部署的。
【讨论】：
这在很大程度上取决于您的项目规模、环境和内部用户群。我很少使用 msi 进行部署，因为我们的操作太小而无法拥有多个环境（SharePoint 除外，这完全不同）。我们开发并使用 VS 将 Web 应用程序部署到开发箱，假设它们被批准然后我们再次使用 VS 部署到 live 箱。
唯一的附带条件是我们有多个 web.config 副本（附加了 test、dev 和 live），然后我们会根据部署位置从相关文件中删除后缀。
这可能不是最好的方法（我知道它不是），但它很有效，并且有助于在小规模用户环境中快速部署中小型解决方案。
【讨论】：
F5ToDebug...
你说如果你没有时间正确地走捷径可以吗？
“谁来测试测试环境中的代码？”你自己说过你有 _test 的配置文件 - 为什么这不是一个合适的测试？
【讨论】：