logo标签列表

逐步 ASP.NET 自动构建/部署

asp.netiisdeployment
30

似乎有很多种不同的自动化构建/部署方式，这使得在网上教程中支持的各种不同场景变得难以解析。因此，我想向stackoverflow群众提出问题...使用以下配置设置自动化构建和部署系统的最佳方法将是什么：

  • Visual Studio 2008
  • Web应用程序项目
  • CruiseControl.NET

我尝试的第一件事是让CCnet自动压缩输出并将其复制到服务器，但这需要在目标位置手动解压缩。然而，如果我们尝试逐个复制所有文件，则可能需要很长时间（如果是大型应用程序，则构建服务器位于我们办公室之外的数据中心...我知道这一点）。

特别感兴趣的另一个问题是如何支持多个环境，因为我们有开发、QA、UAT，当然还有生产环境。

MSDeploy看起来非常有趣，但除非我错误地解释了文献，否则不能帮助从构建服务器的输出进行部署的情况。如果有什么好处，似乎可以在构建农场中部署一个构建 ...但即便是在从一个环境部署到另一个环境时，也需要手动更改配置设置和Web服务URL等。

7个回答
15

我最近花了几天时间在公司自动化部署方面进行工作。

我们使用CruiseControl、NAnt和MSBuild的组合来生成应用程序的发布版本。然后，一个单独的脚本使用MSDeploy和XCopy备份现有网站并传输新文件。

我们的解决方案在回答这个问题时进行了简要描述Automate Deployment for Web Applications?

6

您可能对MSDeploy感兴趣。这是Scott Hanselman发布的一篇文章（链接在此）。目前（2008年9月）它只是一个技术预览版，但值得根据您的需求进行评估。

嗯，虽然看起来很酷......但似乎并没有帮助自动构建的情况（除非我理解文档有误）。 - Joel Martinez
3

有一个新的构建工具（非常智能的包装器）叫做NUBuild。它很轻量，开源且极易设置，几乎不需要维护。我真的很喜欢这个新工具，并将其作为我们项目的持续构建和集成过程的标准工具（我们有大约400个项目，涉及75个开发人员）。试试看吧。

http://nubuild.codeplex.com/

  • 易于使用的命令行界面
  • 能够针对所有 .Net 框架版本进行定位，例如 1.1、2.0、3.0 和 3.5
  • 支持基于 XML 的配置
  • 支持项目和文件引用
  • 自动生成给定项目的“完整有序构建列表”- 几乎不需要维护
  • 能够检测并显示循环依赖项
  • 执行并行构建 - 自动决定可以独立构建生成的构建列表中的哪些项目
  • 能够处理代理程序集
  • 提供视觉线索以显示构建进程，例如显示“% 已完成”、“当前状态”等
  • 生成详细的执行日志，包括 XML 和文本格式
  • 与 Cruise-Control.Net 持续集成系统轻松集成
  • 可以使用自定义记录器，例如针对 2.0 + 版本的 XMLLogger
  • 能够解析错误日志
  • 能够将生成的程序集部署到用户指定位置
  • 能够将源代码与源代码控制系统同步
  • 具备版本管理功能
2
你有远程运行命令的能力吗？PsExec 实用程序来自 Systinternals，可以让你在远程计算机上运行命令行解压缩程序。如果你有一个脚本将构建复制为 .zip 文件到远程站点，你只需要再加一行 PsExec 调用来解压文件即可。
1
这是一个普遍的问题（我希望我早点看到），不仅限于ASP.NET开发。作为其中的一名开发人员，我的团队自然而然地在整个发布流程中内部使用BuildMaster，对于大多数情况来说它是免费的。在该工具中，我们能够执行所有标准CI构建以创建工件，然后设置自动化流程将这些工件部署到我们内部或外部托管的40多个服务器之一，具体取决于特定的应用程序或环境。
由于您特别提到了部署到不同的测试环境，这是该工具的一个基本方面。其想法是模拟您已经拥有的环境工作流程（例如集成->QA->生产），并从源代码控制一直推广到生产环境。大多数时候，只需添加一个部署操作即可将工件部署到环境中，其他时候可能会更加复杂。
您还随意提到配置文件更改是部署的一部分，这是BuildMaster的另一个内置组件。我们的想法是将工具本身用作所有配置文件和部署的中央枢纽，从而确保最新的更改通过部署计划中的简单“部署配置文件”操作自动应用。
在这个过程中，你没有提到与数据库部署相关的事项。大多数ASP.NET应用程序都需要一个关联的数据库，否则它们只能是静态HTML文件。每次部署时更新数据库架构到适当的数据库版本非常重要。不出所料，在BuildMaster中有一个处理此问题的模块。其想法是将DDL-DML脚本存储在工具内部，并通过在每个环境中仅执行脚本一次，确保您的所有数据库随着构建的部署而在每个环境中保持最新。其他脚本（例如存储过程、视图、触发器等）本质上是代码文件，因此属于源代码控制。这些DROP-CREATE-CONFIGURE类型的脚本可以在大多数情况下通过简单的部署操作运行每一次。
部署拼图的另一部分是大多数开发人员不考虑的流程自动化。许多开发人员需要进行签名或填写更改请求表格以手动执行这些过程。同样，这也是BuildMaster自动化工作流设置的一部分。您可以设置阻止器，除非所有单元测试都已通过，否则不允许升级到QA环境，或者阻止升级到Staging环境，除非来自QA团队的某个人批准该构建，并且您的问题跟踪工具中的所有问题都已解决/关闭了该特定版本。

虽然我意识到我的回答中没有提到CC.NET，但我们所有的应用程序都是通过BuildMaster构建和部署的，因此我们不再需要它，尽管我们可以轻松地从一个放置位置获取工件并在后续环境中部署它们。

1
我看到许多人在其.NET项目中使用CC，但为什么不使用Jenkins、Sonarqube呢？它们包含了你所需要的所有内容。我在3天内设置了所有这些内容。我有一个Win 2008服务器R2、MSSQL、Jenkins、VIsual SVN和Sonarqube。
这一切都很好用，您可以得到有关您的项目的所有指标。 Sonarqube使用Gallio、Gendarme、FXcop、Stylecop、NDepths和PartCover来获取您的指标，而且这一切都相当简单，因为SonarQube会自动完成，无需进行太多配置。
我也为您发布了一些图片，以便让您了解情况。这里是构建并获取Sonar指标的Jenkins工作，以及另一个自动部署到IIS的工作。

Sonarqube是一个可以为我的项目提供各项指标的工具。这是一个简单的MVC4应用程序，但它非常出色！

如果您需要更多信息，我可以更具体地解释，但我认为您至少应该考虑Jenkins。如果CC更适合您，至少在选择之前您已经看过一个很好的替代方案。
整个设置都使用MSBuild来构建和部署应用程序。
1

我有一个关于从自动化构建中获取可部署文件集的相关问题。我发现Web Deployment Projects（在旧问题中提供了链接和所有内容）可以满足我的需求 - 它们是VS和MSBuild的附加组件。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接