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

Question

似乎有很多不同的自动化构建/部署的方法，以至于很难解析人们在网络教程中支持的所有不同场景。所以我想向 stackoverflow 人群提出这个问题......使用以下配置设置自动化构建和部署系统的最佳方法是什么：

• 视觉工作室2008
• 网络应用项目
• CruiseControl.NET

我尝试的第一件事是让 CCnet 自动压缩输出并将其复制到服务器，但这需要手动在目的地解压缩。但是，如果我们尝试单独复制所有文件，那么如果它是大型应用程序（构建服务器位于我们办公室的数据中心之外......我知道）。

另外特别令人感兴趣的是我们如何支持多种环境，因为我们有 dev、qa、uat，当然还有 prod。

微软部署 看起来真的很有趣，但除非我错误地解释了文献，否则对于从构建服务器的输出进行部署的场景没有帮助。如果有的话，它似乎对于跨构建场部署一个构建很有用......但即使从一种环境部署到另一种环境，也必须手动更改配置设置和 Web 服务 URL 等。

Answer 1

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

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

我们的解决方案在这个问题的回答中进行了简要描述 自动部署 Web 应用程序？

Answer 2

您可能感兴趣 微软部署. 这是 斯科特·汉塞尔曼 (Scott Hanselman) 对此发表了一篇文章。目前（2008 年 9 月）它仅作为技术预览版提供，但值得根据您的要求进行评估。

Answer 3

还有另一个新的构建工具（一个非常智能的包装器）称为 NUBuild. 。其轻量级、开源且极其易于设置，并提供几乎无接触的维护。我真的很喜欢这个新工具，我们已将其作为我们项目持续构建和集成流程的标准工具（我们有 75 名开发人员的约 400 个项目）。试试看。

http://nubuild.codeplex.com/

• 易于使用的命令行界面
• 能够针对所有.NET框架版本IE1.1、2.0、3.0 和 3.5
• 支持基于XML的配置
• 支持项目和文件参考
• 自动为给定项目生成“完整的订购构建列表” - 无触摸维护。
• 能够检测和显示循环依赖性
• 执行并行构建 - 自动决定可以独立构建生成的构建列表中的哪些项目。
• 处理代理程序集的能力
• 为构建过程提供视觉线索，例如显示“完成的％”，“当前状态”等。
• 生成XML和文本格式的详细执行日志
• 易于与Cruise-Control.net连续集成系统集成
• 定位2.0 +版本时，可以使用自定义记录仪，例如Xmllogger
• 能够解析错误日志
• 能够将已构建的组件部署到用户指定的位置
• 能够将源代码与源控制系统同步的能力
• 版本管理能力

Answer 4

您有能力远程运行命令吗？这 执行程序 效用来自 系统内部 让我们在远程计算机上运行命令行解压缩程序。如果您有一个脚本将构建作为 .zip 文件复制到远程站点，则只需要再一行 PsExec 调用来解压缩文件。

Answer 5

我曾有一个 相关问题 关于从自动构建中获取一组可部署的文件。我发现 Web 部署项目（旧问题中的链接和所有内容）满足了我的需要 - 它们是 VS 和 MSBuild 附加组件。

Answer 6

这是所有开发（而不仅仅是 ASP.NET）的常见问题（我希望我早点读到它）。作为其开发人员之一，我的团队自然使用 建造大师 整个发布过程在内部进行，并且在大多数情况下它是免费的。在该工具中，我们能够执行所有标准 CI 构建来创建工件，然后设置自动化流程以将这些工件部署到我们内部或外部托管的 40 多台服务器中的任何一台，具体取决于特定的应用程序或环境。

由于您特别提到了部署到不同的测试环境，因此这是该工具的一个基本方面。这个想法是对环境工作流程进行建模（例如集成 -> 质量保证 -> 生产）您已经就位，并且实质上促进了从源代码控制到生产的整个构建过程。大多数时候，它就像添加一个将工件部署到环境中的部署操作一样简单，其他时候它可能要复杂得多。

您还随意提到配置文件更改是部署的一部分，这是 BuildMaster 的另一个内置组件。我们的想法是使用该工具本身作为所有配置文件和部署的中心枢纽，从而确保通过部署计划中的简单“部署配置文件”操作自动应用最新更改。

关于此过程您没有提到的一件事是数据库部署方面。大多数 ASP.NET 应用程序都需要关联的数据库，否则它们可能只是静态 HTML 文件。每次部署时数据库架构都更新为适当的数据库版本至关重要。毫不奇怪，BuildMaster 中的一个模块也可以为您处理这个问题。这个想法是将 DDL-DML 脚本存储在工具本身中，并通过执行脚本 只有一次 对于每个环境，它可以确保每个环境中的所有数据库都是最新的，因为您的构建是通过它们部署的。其他脚本（例如存储过程、视图、触发器等）本质上是代码文件，因此属于源代码管理。在大多数情况下，这些 DROP-CREATE-CONFIGURE 类型脚本可以通过简单的部署操作每次运行。

大多数开发人员没有考虑的另一个部署难题是流程自动化。许多开发人员需要执行签核或填写变更请求表单才能手动执行这些过程。同样，这一切都可以作为 BuildMaster 中自动化工作流程设置的一部分来使用。您可以设置阻止程序，除非所有单元测试都已通过，否则不允许升级到 QA 环境，或者阻止升级到暂存环境，除非 QA 团队中的某人批准构建并且问题跟踪工具中的所有问题都已解决/关闭那个特定的版本。

虽然我意识到我在答案中遗漏了 CC.NET，但我们的应用程序都是通过 BuildMaster 构建和部署的，因此我们不再需要它，尽管我们可以轻松地从放置位置拾取工件并将其部署在以后的环境中。

Answer 7

我看到很多人在他们的.NET项目中使用CC，但为什么不使用Jenkins、Sonarqube呢？他们有你需要的一切。我在三天内完成了这一切。我有一个 Win 2008 服务器 R2、MSSQL、Jenkins、VIsual SVN 和 Sonarqube。

一切都很好，您可以获得项目的所有指标。Sonarqube 使用 Gallio、Gendarme、FXcop、Stylecop、NDepths 和 PartCover 来获取您的指标，所有这些都非常简单，因为 SonarQube 无需太多配置即可自动执行此操作。

我给你贴了一些照片，也让你感受一下。这是 Jenkins 女巫构建并获取 Sonar 指标以及自动部署到 IIS 的另一项工作

还有 Sonarqube，我的项目的所有指标。这是一个简单的 MVC4 应用程序，但效果很好！：

如果您想要更多信息，我可以更具体，但我认为您至少应该考虑詹金斯。如果CC更适合你，至少你在选择之前考虑过好的选择。

整个设置使用 MSBuild，也构建和部署应用程序。