我如何以及为什么要设置 C# 构建机器？

How and why do I set up a C# build machine?

提问by mmr

I'm working with a small (4 person) development team on a C# project. I've proposed setting up a build machine which will do nightly builds and tests of the project, because I understand that this is a Good Thing. Trouble is, we don't have a whole lot of budget here, so I have to justify the expense to the powers that be. So I want to know:

我正在与一个 C# 项目的小型（4 人）开发团队合作。我建议设置一台构建机器，它会在每晚进行项目的构建和测试，因为我知道这是一件好事。问题是，我们这里没有很多预算，所以我必须证明这笔费用的合理性。所以我想知道：

What kind of tools/licenses will I need? Right now, we use Visual Studio and Smart Assembly to build, and Perforce for source control. Will I need something else, or is there an equivalent of a cron job for running automated scripts?

我需要什么样的工具/许可证？现在，我们使用 Visual Studio 和 Smart Assembly 进行构建，并使用 Perforce 进行源代码控制。我是否需要其他东西，或者是否有相当于运行自动化脚本的 cron 作业？

What, exactly, will this get me, other than an indication of a broken build? Should I set up test projects in this solution (sln file) that will be run by these scripts, so I can have particular functions tested? We have, at the moment, two such tests, because we haven't had the time (or frankly, the experience) to make good unit tests.

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

What kind of hardware will I need for this?

为此，我需要什么样的硬件？

Once a build has been finished and tested, is it a common practice to put that build up on an ftp site or have some other way for internal access? The idea is that this machine makes thebuild, and we all go to it, but can make debug builds if we have to.

一旦构建完成并经过测试，将构建放在 ftp 站点上或通过其他方式进行内部访问是一种常见的做法吗？我们的想法是，这台机器做的构建，我们都去了，但能让如果我们有调试版本。

How often should we make this kind of build?

我们应该多久进行一次这种构建？

How is space managed? If we make nightly builds, should we keep around all the old builds, or start to ditch them after about a week or so?

空间是如何管理的？如果我们每晚进行构建，我们应该保留所有旧构建，还是在大约一周左右后开始放弃它们？

Is there anything else I'm not seeing here?

I realize that this is a very large topic, and I'm just starting out. I couldn't find a duplicate of this question here, and if there's a book out there I should just get, please let me know.

EDIT: I finally got it to work! Hudson is completely fantastic, and FxCop is showing that some features we thought were implemented were actually incomplete. We also had to change the installer type from Old-And-Busted vdproj to New Hotness WiX.

Basically, for those who are paying attention, if you can run your build from the command line, then you can put it into hudson. Making the build run from the command line via MSBuild is a useful exercise in itself, because it forces your tools to be current.

还有什么我在这里没有看到的吗？

我意识到这是一个非常大的话题，我才刚刚开始。我在这里找不到这个问题的副本，如果有一本我应该得到的书，请告诉我。

编辑：我终于让它工作了！Hudson 非常棒，FxCop 表明我们认为已实现的某些功能实际上并不完整。我们还必须将安装程序类型从 Old-And-Busted vdproj 更改为 New Hotness WiX。

基本上，对于那些正在关注的人来说，如果您可以从命令行运行您的构建，那么您就可以将其放入 hudson。通过 MSBuild 从命令行运行构建本身就是一个有用的练习，因为它强制您的工具是最新的。

采纳答案by Allen Rice

Update: Jenkinsis the most up to date version of Hudson. Everyone should be using Jenkins now. I'll be updating the links accordingly.

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

Hudsonis free and extremely easy to configure and will easily run on a VM.

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

Partly from an old post of mine:

部分来自我的旧帖子：

We use it to

我们用它来

• Deploy Windows services
• Deploy web services
• Run MSTests & display as much information as any junit tests
• Keep track of low,med,high tasks
• trendgraph warnings and errors

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

Here are some of the built in .net stuff that Hudson supports

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

• MSBuild
• NAnt
• MSTest
• Nunit
• Team Foundation Server
• fxcop
• stylecop
• compiler warnings
• code tasks

• MSBuild
• 南特
• 测试
• 纽特
• 团队基础服务器
• 警察
• 风格警察
• 编译器警告
• 代码任务

Also, god forbid you are using visual source safe, it supports that as well. I'd recommend you take a look at Redsolo's article on building .net projects using Hudson

另外，上帝保佑你使用安全的视觉源，它也支持。我建议你看看Redsolo 的关于使用 Hudson 构建 .net 项目的文章

Your questions

你的问题

• Q: What kind of tools/licenses will I need? Right now, we use Visual Studio and Smart Assembly to build, and Perforce for source control. Will I need something else, or is there an equivalent of a cron job for running automated scripts?

• A:I just installed visual studio on a fresh copy of a VM running a fresh, patched, install of a windows server OS. So you'd need the licenses to handle that. Hudson will install itself as a windows service and run on port 8080 and you will configure how often you want it to scan your code repository for updated code, or you can tell it to build at a certain time. All configurable through the browser.

• Q:What, exactly, will this get me, other than an indication of a broken build? Should I set up test projects in this solution (sln file) that will be run by these scripts, so I can have particular functions tested? We have, at the moment, two such tests, because we haven't had the time (or frankly, the experience) to make good unit tests.

  A:You will get an email on the first time a build fails, or becomes unstable. A build is unstable if a unit test fails or it can be marked unstable through any number of criteria that you set. When a unit test or build fails you will be emailed and it will tell you where, why and how it failed. With my configuration, we get:

  • list of all commits since the last working build
  • commit notes of those commits
  • list of files changed in the commits
  • console output from the build itself, showing the error or test failure

• Q:What kind of hardware will I need for this?

  A:A VM will suffice

• Q:Once a build has been finished and tested, is it a common practice to put that build up on an ftp site or have some other way for internal access? The idea is that this machine makes the build, and we all go to it, but can make debug builds if we have to.

  A:Hudson can do whatever you want with it, that includes ID'ing it via the md5 hash, uploading it, copying it, archiving it, etc. It does this automatically and provides you with a long running history of build artifacts.

• Q:How often should we make this kind of build?

  A:We have ours poll SVN every hour, looking for code changes, then running a build. Nightly is ok, but somewhat worthless IMO since what you've worked on yesterday wont be fresh in your mind in the morning when you get in.

• Q:How is space managed? If we make nightly builds, should we keep around all the old builds, or start to ditch them after about a week or so?

  A:Thats up to you, after so long I move our build artifacts to long term storage or delete them, but all the data which is stored in text files / xml files I keep around, this lets me store the changelog, trend graphs, etc on the server with verrrry little space consumed. Also you can set Hudson up to only keep artifacts from a trailing # of builds

• Q:Is there anything else I'm not seeing here?

  A:No, Go get Hudson right now, you wont be disappointed!

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

• 答：我刚刚在运行 Windows 服务器操作系统的全新、修补安装的 VM 的全新副本上安装了 Visual Studio。所以你需要许可证来处理它。Hudson 将自身安装为 Windows 服务并在端口 8080 上运行，您将配置您希望它扫描代码存储库以获取更新代码的频率，或者您可以告诉它在特定时间构建。所有可通过浏览器配置。

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

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

  • 自上次工作构建以来的所有提交列表
  • 提交这些提交的注释
  • 提交中更改的文件列表
  • 构建本身的控制台输出，显示错误或测试失败

• 问：为此我需要什么样的硬件？

  A：一个VM就足够了

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

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

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

  答：我们每小时轮询 SVN，查找代码更改，然后运行构建。Nightly 还可以，但 IMO 有点毫无价值，因为你昨天所做的事情在你早上进来时不会在你的脑海中记忆犹新。

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

  答：这取决于你，经过这么长时间，我将我们的构建工件移动到长期存储或删除它们，但是所有存储在我保留的文本文件/xml 文件中的数据，这让我可以存储变更日志、趋势图，等在服务器上消耗很少的空间。您也可以将 Hudson 设置为仅保留来自尾随构建的工件

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

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

回答by Mike Marshall

We've had great luck with the following combo:

我们非常幸运地使用了以下组合：

1. Visual Studio (specifically, using the MSBuild.exe command line tool and passing it our solution files. removes the need for msbuild scripts)
2. NAnt(like the XML syntax/task library better than MSBuild. Also has options for P4 src control operations)
3. CruiseControl.net- built in web dashboard for monitoring/starting builds.

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

CCNet has built in notifiers to send emails when builds succeed/fail

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

On justification: This takes the load off developers doing manual builds and does a lot to take human error out of the equation. It is very hard to quantify this effect, but once you do it you will never go back. Having a repeatable process to build and release software is paramount. I'm sure you've been places where they build the software by hand and it gets out in the wild, only to have your build guy say "Oops, I must have forgotten to include that new DLL!"

理由：这减轻了开发人员手动构建的负担，并做了很多工作来消除人为错误。这种影响很难量化，但一旦你做到了，你将永远不会回头。拥有一个可重复的过程来构建和发布软件是最重要的。我敢肯定，你去过他们手工构建软件的地方，但它却在野外运行，只是让你的构建人员说“哎呀，我一定忘记包含那个新的 DLL！”

On hardware: as powerful as you can get. More power/memory = faster build times. If you can afford it you'll never regret getting a top-notch build machine, no matter how small the group.

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

On space: Helps to have plenty of hard disk space. You can craft your NAnt scripts to delete intermediate files every time a build starts, so the real issue is keeping log histories and old application installers. We have software that monitors disk space and sends alerts. Then we clean up the drive manually. Usually needs to be done every 3-4 months.

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

On build notifications: This is built in to CCNet, but if you are going to add automated testing as an additional step then build this into the project from the get-go. It is extremely hard to back fit tests once a project gets large. There is tons of info on test frameworks out there (probably a ton of info on SO as well), so I'll defer on naming any specific tools.

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

回答by Daniel Earwicker

The main argument in favour is that it will cut the cost of your development process, by alerting you as soon as possible that you have a broken build or failing tests.

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

The problem of integrating the work of multiple developers is the main danger of growing a team. The larger the team gets, the harder it is to coordinate their work and stop them messing with each other's changes. The only good solution is to tell them to "integrate early and often", by checking in small units of work (sometimes called "stories") as they are completed.

集成多个开发人员的工作的问题是发展团队的主要危险。团队越大，协调他们的工作并阻止他们干扰彼此的更改就越困难。唯一好的解决方案是告诉他们“尽早并经常集成”，通过在完成时检查小的工作单元（有时称为“故事”）。

You should make the build machine rebuild EVERY time some checks in, throughout the day. With Cruise Control, you can get an icon on your task bar that turns red (and even talks to you!) when the build is broken.

您应该在一天中每次进行一些检查时重建构建机器。使用 Cruise Control，您可以在任务栏上看到一个图标，当构建损坏时，该图标会变为红色（甚至会与您交谈！）。

You should then do a nightly full clean build where the source version is labeled (given a unique build number) that you can choose to publish to your stakeholders (product managers, QA people). This is so that when a bug is reported, it is against a known build number (that's extremely important).

然后，您应该每晚进行一次完全干净的构建，其中标记源版本（给定一个唯一的构建编号），您可以选择将其发布给您的利益相关者（产品经理、QA 人员）。这样，当报告错误时，它会针对已知的内部版本号（这非常重要）。

Ideally you should have an internal site where builds can be downloaded, and have a button you can click to publish the previous nightly build.

理想情况下，您应该有一个可以下载构建的内部站点，并有一个按钮，您可以单击以发布之前的每晚构建。

回答by eglasius

It is all about the health of the build. What this gets you is that you can set up any type of things you want to happen with the builds. Among these you can run tests, static analysis, and profiler. Problems are dealt with much much faster, when you recently worked on that part of the application. If you commit small changes, then it almost tells you where you broke it :)

这完全关乎构建的健康。这让您得到的是，您可以设置您希望在构建中发生的任何类型的事情。其中，您可以运行测试、静态分析和分析器。当您最近处理应用程序的那部分时，问题的处理速度要快得多。如果您进行小的更改，那么它几乎会告诉您在哪里破坏它:)

This of course assumes, you set it up to build with every check in (continuous integration).

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

It also can help get QA and Dev closer. As you can set up functional tests to run with it, along with profiler and anything else that improves feedback to the dev team. This doesn't mean the functional tests run with every check in (can take a while), but you set up builds/tests with tools that are common to the whole team. I have been automating smoke tests, so in my case we collaborate even more closely.

它还可以帮助使 QA 和 Dev 更接近。因为您可以设置功能测试来运行它，以及分析器和其他任何可以改进对开发团队的反馈的东西。这并不意味着每次签入都会运行功能测试（可能需要一段时间），但是您可以使用整个团队通用的工具设置构建/测试。我一直在自动化烟雾测试，所以就我而言，我们的合作更加紧密。

回答by The Lazy DBA

Just trying to build a bit on what mjmarsh said, since he laid a great foundation...

只是想在 mjmarsh 所说的基础上建立一点，因为他奠定了很好的基础......

• Visual Studio. MSBuild works fine.
• NAnt.
• NantContrib. This will provide additional tasks such as Perforce operations.
• CruiseControl.net. This is again basically your "build dashboard".

• 视觉工作室。MSBuild 工作正常。
• 南特。
• 南特贡献。这将提供额外的任务，例如 Perforce 操作。
• CruiseControl.net。这又基本上是您的“构建仪表板”。

All of the above (save for VS) is open source, so you're not looking at any additional licensing.

以上所有内容（VS 除外）都是开源的，因此您无需考虑任何其他许可。

As Earwicker mentioned, build early, build often. Knowing something broke, and you can produce a deliverable is useful for catching stuff early on.

正如 Earwicker 所说，尽早构建，经常构建。知道某些事情坏了，您可以生成可交付成果，这对于尽早发现问题很有用。

NAnt includes tasks for nunit/nunit2as well, so you can actually automate your unit testing. You can then apply stylesheets to the results, and with the help of the framework provided by CruiseControl.net, have nice readable, printable unit test results for every build.

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

The same applies to the ndoctask. Have your documentation produced and available, for every build.

这同样适用于ndoc任务。为每个构建制作并提供您的文档。

You can even use the exectask to execute other commands, for instance, producing a Windows Installer using InstallShield.

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

---

---

The idea is to automate the build as much as possible, because human beings make mistakes. Time spent up front is time saved down the road. People aren't having to babysit the build by going through the build process. Identify all the steps of your build, create NAnt scripts for each task, and build your NAnt scripts one by one until you've wholly automated your entire build process. It also then puts all of your builds in one place, which is good for comparison purposes. Something break in Build 426 that worked fine in Build 380? Well, there are the deliverables ready for testing -- grab them and test away.

这个想法是尽可能自动化构建，因为人类会犯错误。在前面花费的时间是在路上节省的时间。人们不必通过构建过程来照看构建。确定构建的所有步骤，为每个任务创建 NAnt 脚本，并一个一个地构建 NAnt 脚本，直到您完全自动化整个构建过程。然后它还会将您的所有构建放在一个地方，这有利于比较。Build 426 中的某些问题在 Build 380 中运行良好？好吧，已经准备好测试的可交付成果——抓住它们并进行测试。

回答by Kenneth Cochran

• No licenses needed. CruiseControl.net is freely available and only needs the .NET sdk to build.
• A build server, even without automated unit tests still provides a controlled environment for building releases. No more "John usually builds on his machine but he's out sick. For some reason I can't build on my machine"
• Right now I have one set up in a Virtual PC session.
• Yes. The build needs to be dumped somewhere accessible. Development builds should have debugging turned on. Release build should have it turned off.
• How often is up to you. If set up correctly, you can build after each check in will very little overhead. This is a great idea if you have (or are planning on having) unit tests in place.
• Keep milestones and releases as long as required. Anything else depends on how often you build: continuously? throw away. Daily? Keep a week's worth. Weekly? Keep two month's worth.

• 不需要许可证。CruiseControl.net 是免费提供的，只需要 .NET sdk 即可构建。
• 构建服务器，即使没有自动化单元测试，仍然为构建发布提供受控环境。不再是“约翰通常在他的机器上构建，但他生病了。出于某种原因，我无法在我的机器上构建”
• 现在我在 Virtual PC 会话中设置了一个。
• 是的。构建需要转储到可访问的地方。开发版本应该打开调试。发布版本应该关闭它。
• 多久一次取决于你。如果设置正确，您可以在每次签入后构建，开销很小。如果您有（或计划有）单元测试，这是一个好主意。
• 根据需要保留里程碑和版本。其他任何事情都取决于您构建的频率：连续？抛弃。日常的？保持一周的价值。每周？保持两个月的价值。

The larger your project gets the more you will see the benefits of an automated build machine.

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

回答by Trumpi

How? Have a look at Carel Lotz's blog.

如何？看看 Carel Lotz 的博客。

Why? There are several reasons that I can think of:

为什么？我能想到的原因有几个：

• A working build, when properly implemented, means that all your developers canbuild on their machine when the build is green
• A working build, when properly implemented, means that you are ready to deploy at any time
• A working build, when properly implemented, means that whatever you release has made a trip to your source control system.
• A working build, when properly implemented, means that you integrate early and often, reducing your integration risk.

• 正确实施的有效构建意味着当构建为绿色时，所有开发人员都可以在他们的机器上构建
• 正确实施的有效构建意味着您可以随时部署
• 一个有效的构建，当正确实施时，意味着您发布的任何内容都已进入您的源代码控制系统。
• 正确实施的有效构建意味着您可以尽早并经常进行集成，从而降低集成风险。

Martin Fowler's article on Continuous Integrationremains the definitive text. Have a look at it!

Martin Fowler 关于持续集成的文章仍然是权威性的文本。看看它！

回答by Jeff

At my previous workplace we used TeamCity. It's very easy and powerful to use. It can be used for free with some restrictions. There is also a tutorial on Dime Casts. The reason we didn't use CruiseControl.NET is that we had a lot of small projects and it's quite painful to set each one up in CC.NET. I would highly recommend TeamCity. To summarize if you are toward open source then CC.NET is the grand daddy with slightly higher learning curve. If your budget allow you definitely go with TeamCity or check out the free version.

在我之前的工作场所，我们使用了TeamCity。它使用起来非常简单和强大。它可以免费使用，但有一些限制。还有一个关于Dime Casts的教程。我们没有使用 CruiseControl.NET 的原因是我们有很多小项目，在 CC.NET 中设置每个项目都非常痛苦。我强烈推荐 TeamCity。总而言之，如果您倾向于开源，那么 CC.NET 是学习曲线稍高的老爹。如果您的预算允许，您肯定会选择 TeamCity 或查看免费版本。

回答by Andrew Gray

Why: 10 years ago we as software developers used to analyse something to the nth degree get the documents (written in a human language) 'signed off' then start writing code. We would unit test, string test and then we would hit system test: the first time the system as a whole would be run together, sometimes week or months after we got the documents signed off. It was only then that we would uncover all the assumptions and misunderstandings we had when we analysed everything.

原因：10 年前，我们作为软件开发人员，过去常常对某些内容进行 n 级分析，然后“签署”文档（以人类语言编写），然后开始编写代码。我们会进行单元测试、字符串测试，然后我们会进行系统测试：整个系统第一次一起运行，有时是在我们签署文件后的几周或几个月。只有到那时，我们才会发现我们分析一切时的所有假设和误解。

Continuous Integration as and idea causes you to build a complete (although, initially, very simple) system end to end. Over time the system functionality is built out orthogonally. Every time you do a complete build you are doing the system test early and often. This means you find and fix bugs and assumptions as early as possible, when it is the cheapest time to fix them.

持续集成和想法使您能够构建一个完整的（尽管最初非常简单）端到端的系统。随着时间的推移，系统功能以正交方式构建。每次进行完整的构建时，您都是在尽早且经常地进行系统测试。这意味着您要尽早发现并修复错误和假设，这是修复它们最便宜的时间。

How: As for the how, I blogged about this a little while ago:[ Click Here]

How：至于how，我前段时间在博客上写过：[点击这里]

Over 8 posts it goes step by step on how to set up a Jenkins server in a windows environment for .NET solutions.

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