我如何以及为什么要设置C＃构建机器？[关闭]

我正在与一个小型的（4人）开发团队一起从事C＃项目。我建议设置一台构建机器，该机器每晚进行项目的构建和测试，因为我知道这是一件好事。麻烦的是，我们在这里没有太多预算，因此我必须将费用证明是合理的。所以我想知道：

更新：Jenkins是Hudson的最新版本。每个人现在都应该使用Jenkins。我将相应地更新链接。

Hudson是免费的，并且非常易于配置，并且可以轻松地在VM上运行。

部分来自我的一个旧职位：

我们用它来

• 部署Windows服务
• 部署网络服务
• 运行MSTests并显示与任何junit测试一样多的信息
• 跟踪低，中，高任务
• 趋势图警告和错误

以下是Hudson支持的一些内置.net内容

• MSBuild
• 南特
• 微软测试
• Nunit
• Team Foundation服务器
• fxcop
• 风格
• 编译器警告
• 代码任务

另外，上帝禁止您使用视觉资源安全，它也支持。我建议您阅读Redsolo的有关使用Hudson构建.net项目的文章

你的问题

• 问：我需要哪种工具/许可证？现在，我们使用Visual Studio和Smart Assembly进行构建，并使用Perforce进行源代码控制。我是否还需要其他东西，或者有等同于cron的工作来运行自动化脚本？

• 答：我刚刚将Visual Studio安装在运行Windows Server OS的最新补丁的VM的新副本上。因此，您需要许可证来处理。Hudson会将其自身安装为Windows服务，并在端口8080上运行，您将配置希望其扫描代码存储库以获取更新代码的频率，或者可以告诉它在特定时间进行构建。所有这些都可以通过浏览器进行配置。

• 问：除了显示损坏的迹象外，这还能给我带来什么？我是否应该在此解决方案（sln文件）中设置将由这些脚本运行的测试项目，以便可以对特定功能进行测试？目前，我们有两个这样的测试，因为我们没有时间（或坦率地说，没有经验）进行好的单元测试。

  答：首次构建失败或变得不稳定时，您会收到一封电子邮件。如果单元测试失败，则构建不稳定，或者可以通过您设置的任何数量的标准将其标记为不稳定。如果单元测试或构建失败，则会通过电子邮件发送给您，并告诉您失败的位置，原因和方式。通过我的配置，我们得到：

  • 自上次运行构建以来的所有提交列表
  • 提交那些提交的笔记
  • 提交中更改的文件列表
  • 生成本身的控制台输出，显示错误或测试失败

• 问：我需要哪种硬件？

  答：虚拟机就足够了

• 问：构建完成并经过测试后，将构建的内容放置在ftp站点上还是采用其他内部访问方式是一种常见的做法？这个想法是由这台机器来完成构建的，我们都去做，但是如果需要的话可以进行调试构建。

  答： Hudson可以用它做任何您想做的事情，包括通过md5哈希对它进行ID，上传，复制，存档等。它会自动执行此操作，并为您提供长期的构建工件历史。

• 问：我们应该多久进行一次此类构建？

  答：我们每小时进行一次SVN调查，查找代码更改，然后运行构建。Nightly还可以，但是IMO毫无价值，因为您昨天进行的工作不会在早上进入您的脑海中浮现。

• 问： 如何管理空间？如果我们每晚进行构建，我们应该保留所有旧构建，还是大约一周后开始弃用它们？

  答：由您决定，经过很长时间之后，我将构建工件移至长期存储中或将其删除，但是存储在文本文件/ xml文件中的所有数据都保留在其中，这使我可以存储变更日志，趋势图，等在服务器上消耗很少的空间。您也可以将Hudson设置为仅保留后续版本中的工件

• 问：还有什么我没看到的吗？

  A：不，现在就去找哈德森，您不会失望的！

以下组合给我们带来了好运：

1. Visual Studio（特别是，使用MSBuild.exe命令行工具并将其传递给我们的解决方案文件。从而无需使用msbuild脚本）
2. NAnt（例如比MSBuild更好的XML语法/任务库。还具有用于P4 src控制操作的选项）
3. CruiseControl.net-内置Web仪表板，用于监视/开始构建。

CCNet内置了通知程序，以在构建成功/失败时发送电子邮件

合理性：这减轻了开发人员进行手动构建的负担，并且在消除人为错误方面做了大量工作。量化这种影响非常困难，但是一旦您做到了，您将永不退缩。具有可重复的过程来构建和发布软件是至关重要的。我敢肯定，您到过那里的地方，他们都是手工构建软件的，并且疯狂地发行了它，只是让您的构建人员说：“糟糕，我一定忘了包含新的DLL！”

关于硬件：尽可能强大。更大的功耗/内存=更快的构建时间。如果负担得起的话，无论团队多小，您都永远不会后悔获得一流的构建机器。

节省空间：帮助拥有足够的硬盘空间。您可以构建NAnt脚本以在每次构建开始时删除中间文件，因此真正的问题是保留日志历史记录和旧的应用程序安装程序。我们有监视磁盘空间并发送警报的软件。然后，我们手动清理驱动器。通常需要每3-4个月执行一次。

关于构建通知：这是CCNet内置的，但是如果要添加自动测试作为附加步骤，则可以从一开始就将其构建到项目中。一旦项目变大，就很难进行拟合测试。那里有大量有关测试框架的信息（也可能有大量有关SO的信息），因此我不愿命名任何特定的工具。

在我以前的工作场所中，我们使用了TeamCity。它非常易于使用且功能强大。有一定限制，它可以免费使用。关于Dime Casts也有一个教程。我们不使用CruiseControl.NET的原因是我们有很多小项目，而在CC.NET中设置每个项目都非常痛苦。我强烈推荐TeamCity。总结一下，如果您是开源的，那么CC.NET是学习曲线稍高的老爸。如果您的预算允许，您肯定会选择TeamCity或查看免费版本。

怎么样？看看Carel Lotz的博客。

为什么？我可以想到以下几个原因：

• 正确实施的有效构建意味着在构建为绿色时，所有开发人员都可以在其计算机上进行构建
• 正确实施的有效构建意味着您随时可以进行部署
• 一个有效的构建，如果正确实施，则意味着您发布的任何版本都可以访问源代码控制系统。
• 正确实施的有效构建意味着您可以尽早且经常进行集成，从而降低了集成风险。

马丁·福勒（Martin Fowler）关于持续集成的文章仍然是权威文章。看看它！

支持的主要论点是，它会通过提醒您构建失败或测试失败而尽快降低开发过程的成本。

集成多个开发人员的工作的问题是组建团队的主要危险。团队越大，越难以协调他们的工作并阻止他们彼此改变。唯一好的解决方案是，通过在完成工作时签入较小的工作单元（有时称为“故事”），告诉他们“尽早集成”。

您应该使构建机器在每天的每一次检查中都重新构建。使用Cruise Control，您可以在任务栏上看到一个图标，当构建中断时，该图标会变成红色（甚至与您对话！）。

然后，您应该每晚进行一次完整的内部构建，其中标记了源版本（具有唯一的内部版本号），您可以选择将其发布给利益相关者（产品经理，质量检查人员）。这样一来，当报告错误时，它将针对已知的内部版本号（这一点非常重要）。

理想情况下，您应该具有一个内部站点，可以在其中下载内部版本，并可以单击一个按钮以发布以前的每晚内部版本。

自从mjmarsh讲了一个很好的基础以来，他只是想在他的话语上做一点点...

• 视觉工作室。MSBuild正常工作。
• NAnt。
• NantContrib。这将提供其他任务，例如Perforce操作。
• CruiseControl.net。基本上，这又是您的“构建仪表板”。

以上所有内容（针对VS的保存）都是开源的，因此您无需查看任何其他许可。

正如Earwicker所说，尽早建立，经常建立。知道发生了什么事情，并且可以产生可交付成果，对于早期发现问题很有用。

NAnt还包括用于nunit / nunit2的任务，因此您实际上可以自动化单元测试。然后，您可以将样式表应用于结果，并在CruiseControl.net提供的框架的帮助下，对每个构建都有清晰易读的可打印单元测试结果。

这同样适用于ndoc任务。为每个版本生成并提供您的文档。

您甚至可以使用exec任务来执行其他命令，例如，使用InstallShield生成Windows Installer。

这样做的想法是尽可能使构建自动化，因为人类会犯错误。预先花费的时间就是节省下来的时间。人们不必通过构建过程来照看构建。识别构建的所有步骤，为每个任务创建NAnt脚本，并一个一个地构建NAnt脚本，直到完全自动化整个构建过程。然后，它还将所有构建都放在一个位置，这对于比较而言很有用。Build 426中的某些中断在Build 380中工作正常吗？好了，有交付物可供测试了-抓住它们并进行测试。

• 无需许可证。CruiseControl.net是免费提供的，只需要.NET SDK即可构建。
• 即使没有自动单元测试，构建服务器仍可为构建发行版提供受控环境。不再有“ John通常在他的机器上构建，但他病了。出于某种原因，我无法在我的机器上构建”
• 现在，我在Virtual PC会话中进行了设置。
• 是。该构建需要转储到易于访问的位置。开发版本应已打开调试。发布版本应将其关闭。
• 多久取决于您一次。如果设置正确，您可以在每次签入后进行构建，因此开销很少。如果您已经（或计划进行）单元测试，这是一个好主意。
• 保持里程碑和发布时间尽可能长。还有什么取决于您构建的频率：持续不断？丢弃。日常？保持一周的价值。每周？保留两个月的价值。

您的项目越大，越能看到自动化构建机器的好处。

一切都与构建的健康有关。这给您带来的好处是，您可以设置要在构建中发生的任何类型的事情。其中，您可以运行测试，静态分析和分析器。当您最近在应用程序的那部分工作时，问题的处理速度要快得多。如果您进行小的更改，那么它几乎可以告诉您在哪里中断了它:)

当然，这假定您将其设置为每次签入时都进行构建（连续集成）。

它还可以帮助您进一步提高质量检查和开发水平。正如您可以设置功能测试以与之一起运行，以及探查器和任何其他可以改善对开发团队的反馈的工具。这并不意味着功能测试会在每次检入时运行（可能要花一些时间），但是您会使用整个团队通用的工具来进行构建/测试。我一直在进行烟雾测试的自动化，因此就我而言，我们之间的合作更加紧密。

为什么：10年前，作为软件开发人员，我们习惯于对事物进行n级分析，然后将文档（以人类语言编写）“签名”，然后开始编写代码。我们将进行单元测试，字符串测试，然后进行系统测试：第一次将整个系统运行在一起，有时是在签署文档后的几周或几个月。只有到那时，我们才能揭露我们分析所有内容时遇到的所有假设和误解。

持续集成的构想使您可以端到端构建一个完整的（尽管最初非常简单）系统。随着时间的流逝，系统功能会逐步建立。每次进行完整的构建时，您都会尽早且经常进行系统测试。这意味着您应该尽早发现并修复错误和假设，这是最便宜的时间来修复它们。

方式：关于方式，我前段时间在此发布了博客：[ 点击这里 ]

在8篇文章中，它逐步介绍了如何在Windows环境中为.NET解决方案设置Jenkins服务器。