我正在与一个小型（4 人）开发团队合作开发一个 C# 项目。我建议设置一台构建机器，它会在夜间对项目进行构建和测试，因为我知道这是一件好事。麻烦的是，我们这里没有很多预算，所以我必须向当权者证明费用是合理的。所以我想知道：
我意识到这是一个非常大的话题，而我才刚刚开始。我在这里找不到这个问题的副本，如果那里有我应该得到的书，请告诉我。
编辑：我终于让它工作了！Hudson 非常棒，FxCop 表明我们认为实现的一些功能实际上是不完整的。我们还必须将安装程序类型从 Old-And-Busted vdproj 更改为 New Hotness WiX。
基本上，对于那些关注的人来说，如果您可以从命令行运行您的构建，那么您可以将其放入 hudson。通过 MSBuild 从命令行运行构建本身就是一个有用的练习，因为它强制您的工具是最新的。
更新：Jenkins是 Hudson 的最新版本。现在每个人都应该使用 Jenkins。我将相应地更新链接。
Hudson是免费的，并且非常易于配置，并且可以轻松地在 VM 上运行。
部分来自我的旧帖子：
我们用它来
以下是 Hudson 支持的一些内置 .net 内容
另外，上帝禁止你使用安全的视觉源，它也支持。我建议你看看Redsolo 关于使用 Hudson 构建 .net 项目的文章
你的问题
问：我需要什么样的工具/许可证？现在，我们使用 Visual Studio 和 Smart Assembly 进行构建，使用 Perforce 进行源代码控制。我是否需要其他东西，或者是否有相当于运行自动化脚本的 cron 作业？
答：我刚刚在一个新的虚拟机副本上安装了 Visual Studio，该虚拟机运行一个全新的、修补过的、安装的 Windows 服务器操作系统。所以你需要许可证来处理它。Hudson 将自己安装为 Windows 服务并在端口 8080 上运行，您将配置您希望它扫描您的代码存储库以获取更新代码的频率，或者您可以告诉它在特定时间构建。所有这些都可以通过浏览器进行配置。
问：除了表明构建损坏之外，这究竟会给我带来什么？我是否应该在此解决方案（sln 文件）中设置将由这些脚本运行的测试项目，以便我可以测试特定的功能？目前，我们有两个这样的测试，因为我们没有时间（或者坦率地说，经验）来进行良好的单元测试。
答：您将在第一次构建失败或变得不稳定时收到一封电子邮件。如果单元测试失败，或者可以通过您设置的任意数量的标准将其标记为不稳定，则构建是不稳定的。当单元测试或构建失败时，您将收到电子邮件，它会告诉您失败的位置、原因和方式。通过我的配置，我们得到：
问：我需要什么样的硬件？
A：一个虚拟机就足够了
问：一旦构建完成并经过测试，通常的做法是将构建放在 ftp 站点上还是通过其他方式进行内部访问？这个想法是这台机器进行构建，我们都去它，但如果我们必须进行调试构建。
答： Hudson 可以用它做任何你想做的事情，包括通过 md5 哈希对其进行标识、上传、复制、归档等。它会自动执行此操作，并为您提供长期运行的构建工件历史。
问：我们应该多久进行一次这种构建？
答：我们每小时轮询一次 SVN，寻找代码更改，然后运行构建。每晚都可以，但在 IMO 中有点毫无价值，因为您昨天所做的工作在您早上进来时不会在您的脑海中浮现。
问： 空间如何管理？如果我们在夜间进行构建，我们应该保留所有旧构建，还是在大约一周左右后开始放弃它们？
A：这取决于你，经过这么长时间我将我们的构建工件移动到长期存储或删除它们，但所有存储在我保留的文本文件/xml文件中的数据，这让我可以存储更改日志、趋势图、等在服务器上消耗很少的空间。您还可以将 Hudson 设置为仅保留来自尾随 # 构建的工件
问：还有什么我在这里没有看到的吗？
A:不，现在就去找哈德森，你不会失望的！
我们对以下组合非常幸运：
CCNet 内置了在构建成功/失败时发送电子邮件的通知器
关于理由：这减轻了开发人员进行手动构建的负担，并在很大程度上消除了人为错误。很难量化这种影响，但一旦你做到了，你就永远不会回头。拥有一个可重复的过程来构建和发布软件是至关重要的。我敢肯定，您曾经去过他们手工构建软件的地方，并且它在野外传播，只是让您的构建人员说“糟糕，我一定忘记包含那个新的 DLL！”
在硬件上：尽可能强大。更多功率/内存 = 更快的构建时间。如果你能负担得起，你永远不会后悔得到一台一流的构建机器，无论团队有多小。
在空间上：有助于拥有足够的硬盘空间。您可以制作您的 NAnt 脚本以在每次构建开始时删除中间文件，因此真正的问题是保留日志历史记录和旧的应用程序安装程序。我们有监控磁盘空间和发送警报的软件。然后我们手动清理驱动器。通常需要每3-4个月进行一次。
关于构建通知：这是内置在 CCNet 中的，但如果您要添加自动化测试作为附加步骤，请从一开始就将其构建到项目中。一旦项目变大，就很难进行回拟合测试。那里有大量关于测试框架的信息（可能也有大量关于 SO 的信息），所以我将推迟命名任何特定工具。
在我以前的工作场所，我们使用了TeamCity。它使用起来非常简单且功能强大。它可以免费使用，但有一些限制。还有一个关于Dime Casts的教程。我们没有使用 CruiseControl.NET 的原因是我们有很多小项目，在 CC.NET 中设置每个项目非常痛苦。我强烈推荐 TeamCity。总结一下，如果你是开源的，那么 CC.NET 是学习曲线稍高的老爹。如果您的预算允许，您肯定会选择 TeamCity 或查看免费版本。
赞成的主要论点是，它将通过尽快提醒您构建损坏或测试失败来降低开发过程的成本。
集成多个开发人员的工作的问题是发展团队的主要危险。团队越大，就越难协调他们的工作并阻止他们互相干扰对方的更改。唯一好的解决方案是告诉他们“尽早并经常集成”，方法是在完成时检查小型工作单元（有时称为“故事”）。
您应该在一天中每次签入时都重建构建机器。使用 Cruise Control，您可以在任务栏上看到一个图标，该图标会在构建损坏时变为红色（甚至与您对话！）。
然后，您应该每晚进行一次完整的干净构建，其中标记了源版本（给定一个唯一的构建号），您可以选择将其发布给您的利益相关者（产品经理、QA 人员）。这样一来，当报告错误时，它会针对已知的内部版本号（这非常重要）。
理想情况下，您应该有一个可以下载构建的内部站点，并有一个可以单击以发布以前的夜间构建的按钮。
只是想在 mjmarsh 所说的基础上有所建树，因为他奠定了良好的基础......
以上所有内容（除了 VS）都是开源的，因此您无需考虑任何额外的许可。
正如 Earwicker 所说，尽早构建，经常构建。知道有什么东西坏了，你可以生产一个可交付的东西，这对于及早发现东西很有用。
NAnt 还包括nunit / nunit2的任务，因此您实际上可以自动化您的单元测试。然后，您可以将样式表应用于结果，并在 CruiseControl.net 提供的框架的帮助下，为每个构建提供可读、可打印的单元测试结果。
这同样适用于ndoc任务。为每个构建制作并提供您的文档。
您甚至可以使用exec任务来执行其他命令，例如，使用 InstallShield 生成 Windows Installer。
这个想法是尽可能地自动化构建，因为人类会犯错误。在前面花费的时间是在路上节省的时间。人们不必通过构建过程来照看构建。确定构建的所有步骤，为每个任务创建 NAnt 脚本，并一个一个地构建您的 NAnt 脚本，直到您完全自动化整个构建过程。然后它还将您的所有构建放在一个地方，这有利于比较。Build 426 中的某些问题在 Build 380 中运行良好？好吧，已经准备好测试的可交付成果——抓住它们并进行测试。
您的项目越大，您就越能看到自动构建机器的好处。
这一切都与构建的健康有关。这让你得到的是，你可以设置任何你想在构建中发生的事情。其中，您可以运行测试、静态分析和分析器。当您最近处理应用程序的那部分时，问题的处理速度要快得多。如果您提交小的更改，那么它几乎会告诉您您在哪里破坏了它:)
这当然假设，您将其设置为在每次签入时构建（持续集成）。
它还可以帮助 QA 和 Dev 更紧密地联系起来。因为您可以设置功能测试来运行它，以及分析器和其他任何改进对开发团队的反馈的东西。这并不意味着每次签入都会运行功能测试（可能需要一段时间），而是您使用整个团队通用的工具设置构建/测试。我一直在自动化烟雾测试，所以就我而言，我们的合作更加密切。
原因：10 年前，作为软件开发人员，我们习惯于对某事进行第 n 级分析，得到文件（用人类语言编写）“签字”，然后开始编写代码。我们会进行单元测试、字符串测试，然后进行系统测试：第一次将整个系统作为一个整体一起运行，有时是在我们签署文件后数周或数月。只有到那时，我们才会发现我们在分析一切时的所有假设和误解。
持续集成和想法使您能够构建一个完整的（尽管最初非常简单）端到端的系统。随着时间的推移，系统功能会正交构建。每次您进行完整的构建时，您都在尽早且经常地进行系统测试。这意味着您可以尽早发现并修复错误和假设，此时修复它们的成本最低。
如何：至于如何，我前一阵子写过这个：[点击这里]
超过 8 篇文章逐步介绍了如何在 Windows 环境中为 .NET 解决方案设置 Jenkins 服务器。