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