如何以及为什么设置C＃构build机器？
我正在与一个C＃项目的小型（4人）开发团队合作。 我build议设立一个build造机器，每晚都会build造和testing项目，因为我明白这是一件好事。 麻烦的是，我们在这里没有太多的预算，所以我必须certificate这些费用是合理的。 所以我想知道：
我意识到这是一个非常大的话题，我刚刚开始。 在这里我找不到这个问题的重复，如果有一本书我应该得到，请让我知道。
编辑：我终于得到它的工作！ 哈德森是完全不可思议的，FxCop显示我们认为实现的一些function实际上是不完整的。 我们还必须将安装程序types从旧的vdproj更改为新的Hotness WiX。
基本上，对于那些正在关注的人，如果你可以从命令行运行你的构build，那么你可以把它放入哈德森。 通过MSBuild从命令行运行构build本身是一个有用的练习，因为它会迫使您的工具变得最新。
更新： jenkins是哈德逊的最新版本。 现在每个人都应该使用Jenkins。 我会相应地更新链接。
Hudson是免费的，并且非常容易configuration，并且可以轻松在虚拟机上运行。
部分来自我的一个旧post：
我们用它来
- 部署Windows服务
- 部署Web服务
- 运行MSTests并显示与任何junittesting一样多的信息
- 跟踪低，中等，高任务
- trendgraph警告和错误
这里是一些Hudson支持的.net内容
- 的MSBuild
- 楠
- MSTest的
- NUnit的
- 团队基础服务器
- 的FxCop
- 了StyleCop
- 编译器警告
- 代码任务
此外，上帝禁止你使用视觉资源安全， 它也支持 。 我build议你看看Redsolo关于使用Hudson构build.net项目的文章
你的问题
-
问 ：我需要什么样的工具/许可证？ 现在，我们使用Visual Studio和Smart Assembly来构build，而使用Perforce进行源代码pipe理。 我需要其他的东西，还是有相当于一个cron作业来运行自动脚本？
-
答：我刚安装了一个运行全新的，修补过的，安装了Windows服务器操作系统的虚拟机的全新副本。 所以你需要许可证来处理。 哈德森将自己安装为一个Windows服务，并运行在端口8080上，您将configuration您希望扫描代码库以更新代码的频率，或者您可以指定它在某个特定时间生成。 所有可通过浏览器进行configuration。
-
问：除了表示破损的构造外，这究竟会给我带来什么？ 我应该在这个解决scheme（sln文件）中设置testing项目，这些脚本将运行testing项目，所以我可以testing特定的function？ 目前我们有两个这样的testing，因为我们没有时间（或坦率地说，是经验）做好unit testing。
答：第一次生成失败或者变得不稳定时，您将收到一封电子邮件。 如果unit testing失败或者可以通过您设置的任意数量的标准将其标记为不稳定，则构build不稳定。 当unit testing或构build失败时，您将通过电子邮件发送，它会告诉您在哪里，为什么以及如何失败。 用我的configuration，我们得到：
- 自上次构build以来所有提交的列表
- 提交这些提交的logging
- 在提交中更改的文件列表
- 从构build本身的控制台输出，显示错误或testing失败
-
问：我需要什么样的硬件？
答：虚拟机就足够了
-
问：构build完成并testing后，将其构build在ftp站点上还是采取其他方式进行内部访问是常见做法？ 这个想法是，这台机器进行构build，我们都去，但如果必须的话，可以debugging构build。
答：哈德森可以随心所欲地做任何事情，包括通过md5哈希对其进行身份validation，上传，复制，归档等等。它会自动执行此操作，并为您提供构build工件的长期历史logging。
-
问：我们应该多久进行一次这种构build？
答：我们每小时都有我们的poll SVN，查找代码更改，然后运行构build。 每晚都没问题，但是有些没有价值的海事组织，因为你昨天的工作不会在你进入的时候在你的脑海里变得清新。
-
问：如何pipe理空间？ 如果我们每晚build造，我们应该保留所有的旧build筑物，还是在大约一个星期左右之后开始抛弃它们？
– 答：这是由你，经过这么长时间，我把我们的构build文物长期存储或删除它们，但所有的数据存储在文本文件/ xml文件我保持，这让我存储changelog，趋势图，等在服务器上消耗less量空间。 你也可以将Hudson设置为只保留尾随编号的文物
-
问：还有什么我没看到的吗？
答：不，现在就去哈德森，你不会失望！
我们有以下的组合运气很好：
- Visual Studio（具体地说，使用MSBuild.exe命令行工具并将它传递给我们的解决scheme文件，不需要msbuild脚本）
- NAnt （比MSBuild更好的XML语法/任务库，还有用于P4 src控制操作的选项）
- CruiseControl.net – 内置在网页仪表板中监视/启动构build。
CCNet内置通知程序在构build成功/失败时发送电子邮件
理由：这样做会减轻开发人员进行手动构build的负担，而且还会大大减less人为错误。 量化这个效应是非常困难的，但是一旦你做到了，你将永远不会回头。 有一个可重复的过程来build立和发布软件是最重要的。 我相信你一直是他们手工build立这个软件的地方，只是为了让你的搭build人员说“糟糕，我一定忘记包含这个新的DLL！
在硬件上：尽可能强大。 更多的功耗/内存=更快的编译时间。 如果你能负担得起，不pipe你的团队多么小，你永远不会后悔拿到一台顶尖的打造机器。
在空间上：有助于有足够的硬盘空间。 您可以制作您的NAnt脚本以在每次构build开始时删除中间文件，所以真正的问题是保存日志历史logging和旧的应用程序安装程序。 我们有监控磁盘空间并发送警报的软件。 然后我们手动清理驱动器。 通常需要每3-4个月进行一次。
关于构build通知：这是内置于CCNet的，但是如果您要添加自动化testing作为额外的步骤，则可以从一开始就将其构build到项目中。 一旦项目变大，回溯testing非常困难。 那里有很多关于testing框架的信息（可能还有很多关于SO的信息），所以我会推迟命名任何特定的工具。
在我以前的工作场所，我们使用了TeamCity 。 使用起来非常简单而且function强大。 它可以免费使用，有一些限制。 Dime Casts也有一个教程。 我们没有使用CruiseControl.NET的原因是我们有很多小的项目，并且在CC.NET中设置每个项目都是非常痛苦的。 我会强烈推荐TeamCity。 总结一下，如果你是开源的，那么CC.NET就是一个学习曲线稍高的大爸爸。 如果你的预算允许你一定要与TeamCity一起或检查出免费版本。
怎么样？ 看看Carel Lotz的博客 。
为什么？ 我能想到的有几个原因：
- 正确实施的工作构build意味着当构build为绿色时，所有开发人员都可以在其计算机上构build
- 正确实施的工作版本意味着您随时可以部署
- 正确实施的工作构build意味着，无论您发布什么内容，都会使您的源代码pipe理系统访问。
- 正确实施的工作构build意味着您可以尽早整合，降低整合风险。
Martin Fowler关于持续集成的文章仍然是权威文本。 看看它！
赞成的主要观点是，它会降低开发过程的成本，通过尽快提醒您已经破损或者testing失败。
整合多个开发商的工作的问题是成长一个团队的主要危险。 团队越大，协调他们的工作就越困难，阻止他们混淆彼此的变化。 唯一好的解决办法就是告诉他们“尽早和经常融合”，办法是在完成工作时检查一小部分工作（有时称为“故事”）。
你应该让整个机器在整个一天内重build每一次检查。 使用巡航控制，你可以在任务栏上看到一个红色的图标（甚至和你说话！）。
然后，您应该在源版本标签（给定一个唯一的内部版本号）的情况下每晚做一次完整的清理版本，您可以select发布给您的利益相关者（产品经理，质量保证人员）。 这是为了当一个错误报告时，它是反对已知的内部版本号（这是非常重要的）。
理想情况下，你应该有一个内部网站，可以下载构build，并有一个button，您可以点击发布以前的每晚构build。
只是试图build立一个什么mjmarsh说，因为他奠定了一个伟大的基础…
- 视觉工作室。 MSBuild工作正常。
- NAnt 。
- NantContrib 。 这将提供额外的任务，如Perforce操作。
- CruiseControl.net 。 这基本上是你的“构build仪表板”。
以上所有（除了VS）都是开源的，所以你不需要额外的授权。
正如Earwicker所说，build设早，经常build设。 知道一件事情破灭了，你可以产生一个交付物，对于早日捕捉东西很有用。
NAnt也包括nunit / nunit2的任务，所以你可以实际上自动化你的unit testing。 然后，您可以将样式表应用于结果，并在CruiseControl.net提供的框架的帮助下，为每个构build提供可读的，可打印的unit testing结果。
这同样适用于ndoc任务。 让您的文档生成和可用，为每个版本。
您甚至可以使用exec任务来执行其他命令，例如，使用InstallShield生成Windows Installer。
这个想法是尽可能地自动化构build，因为人类会犯错误。 在前面花费的时间是节省下来的时间。 人们不必通过构build过程来保护构build。 确定构build的所有步骤，为每个任务创buildNAnt脚本，然后逐个构buildNAnt脚本，直到完全自动化整个构build过程。 它也将所有的构build放在一个地方，这是比较好的。 Build 390在Build 380中可以正常工作吗？ 那么，这些交付物已经准备好进行testing了 – 抓住它们并且试验一下。
- 不需要许可证。 CruiseControl.net是免费的，只需要.NET SDK构build。
- 即使没有自动化的unit testing，构build服务器仍然为构build版本提供受控环境。 没有更多的“约翰通常build立在他的机器上，但他病了，出于某种原因，我不能build立在我的机器上”
- 现在我有一个在虚拟PC会话中设置。
- 是。 构build需要倾倒在可访问的地方。 开发版本应该打开debugging。 发布版本应该closures它。
- 多久是由你决定。 如果设置正确，你可以在每次入住后build立很less的开销。 如果你有（或正在计划进行）unit testing，这是一个好主意。
- 保持里程碑和释放，只要需要。 还有什么要看你多久build立一次？ 丢掉。 日常？ 保持一周的价值。 每周？ 保持两个月的价值。
您的项目越大，您将看到自动生成机器的好处。
这是关于build设的健康。 这是什么让你可以设置任何types的事情，你想与build设发生。 其中您可以运行testing，静态分析和分析器。 当你最近在应用程序的那一部分工作时，问题处理速度要快得多。 如果你做了小小的改动，那么它几乎可以告诉你你在哪里弄坏了它:)
这当然假设，你设置它与每一个检查（持续集成）build立。
它也可以帮助QA和Dev更接近。 正如你可以设置functiontesting来运行它，以及探查器和其他任何改善对开发团队反馈的东西。 这并不意味着每次检查都会运行functiontesting（可能需要一段时间），但是您使用整个团队常见的工具来设置构build/testing。 我一直在自动化烟雾testing，所以在我的情况下，我们更密切合作。
为什么：10年前，我们作为软件开发人员用来分析一些东西到第n级获得文件（用人类语言写的）“签字”，然后开始编写代码。 我们将进行unit testing，stringtesting，然后进行系统testing：整个系统第一次一起运行，有时在签署文档之后的一周或几个月。 只有到那时，我们才能发现我们分析一切时所有的假设和误解。
持续集成作为和理念使您能够build立一个完整的（尽pipe最初非常简单）的系统。 随着时间的推移，系统function是正交构build的。 每次你做一个完整的构build你都在做早期和经常的系统testing。 这意味着您可以尽早find并修复错误和假设，而修复这些错误和假设是最便宜的时间。
怎么样：至于怎么，我刚才在博客上写了这个：[ 点击这里 ]
超过8篇文章，一步一步地介绍如何在.NET解决scheme的windows环境中设置Jenkins服务器。
