6

我们目前通过创建数据库并通过查询分析器运行 SQL 脚本来部署 Web 应用程序。然后我们从“发布网站”复制输出并在 IIS 中设置该网站。

我们已经在 Visual Studio 中看到了 websetup，但该部分似乎没有什么文档。例如，我们不清楚如何向用户询问 SQL 服务器的 IP 和密码。我们也倾向于以这种方式部署的网站出现在http://example.com/project之类的文件夹下，而不仅仅是http://example.com。

然后存在未安装 AJAX.Net 或未应用某些或其他补丁的问题。

到目前为止，我们可以物理访问服务器。很快，虽然我们将要运送 CDROM。人工干预和自动化之间的实际权衡是什么？

4

3 回答 3

7

避免 Visual Studio 部署，并尽可能自动化。Web 部署项目和 NAnt 可以成为你的朋友！

简而言之，我们的部署设置：

  1. 我们使用 RedGate SQL 编写开发数据库和实时数据库之间的差异脚本。

  2. 一个调用 MSBUILD 来构建 Web 部署项目 (.wdproj) 的 NAnt 构建文件，压缩生成的已编译 Web 应用程序（连同 SQL 更改脚本），然后将 zip 文件上传到服务器。

  3. 在服务器端，还有另一个 NAnt 构建文件，它使应用程序脱机、备份数据库、备份网站。运行 SQL 更改脚本，解压缩新版本并使应用程序联机。

第 3 步通常是“手动”运行（双击），但有时会安排在深夜。您可以从 CDROM 执行完全相同的操作，甚至可以编写一个非常小的 Windows 窗体应用程序作为包装器。

如果您有兴趣，很乐意提供 NAnt 脚本的详细信息。

于 2008-09-15T13:31:52.730 回答
2

您是否尝试过使用Web 部署项目？现在也支持VS 2008 ..

于 2008-09-15T13:27:24.037 回答
0

我主要将 ASP.NET 应用程序部署到 Linux 服务器。这是我的标准工作流程：

  • 我使用源代码存储库（如 Subversion）
  • 在服务器上，我有一个执行以下操作的 bash 脚本：
    • 查看最新代码
    • 进行构建（创建 DLL）
    • 将文件过滤到基本要素（例如删除代码文件）
    • 备份数据库
    • 将文件部署到以当前日期命名的目录中的 Web 服务器
    • 如果部署中包含新架构，则更新数据库
    • 使新安装成为默认安装，以便下次命中时提供

Checkout 是使用 Subversion 的命令行版本完成的，而构建是使用 xbuild 完成的（与 Mono 项目中的 msbuild 工作类似）。大多数魔法都是在 ReleaseIt 中完成的。

在我的开发服务器上，我基本上有持续集成，但在生产端，我实际上是通过 SSH 连接到服务器并通过运行脚本手动启动部署。我的脚本被巧妙地称为“部署”，这就是我在 bash 提示符下键入的内容。我很有创意。不是。

在生产环境中，我必须输入“deploy”两次：一次是签出、构建和部署到一个过时的目录，一次是将该目录设置为默认实例。由于目录已过时，我只需在相关目录中键入“deploy”即可恢复到任何以前的部署。

初始部署需要几分钟，恢复到以前的版本需要几秒钟。

它对我来说是一个很好的解决方案，并且只依赖于三个命令行实用程序（svn、xbuild 和 releaseit）、DB 客户端、SSH 和 Bash。

我真的需要有时在 CodePlex 上更新 ReleaseIt 的副本：

http://releaseit.codeplex.com/

于 2010-07-21T19:20:49.590 回答