使用NUnit 2.5.x和.Net 4.0进行持续集成/构建

Question

好的，这是我目前的设置和问题。我有一组在Visual Studio解决方案中的项目。该解决方案包含大约15个项目（或多或少）和不断增长的代码库。我意识到在开始之前应该设置一个持续构建系统，但我想现在也不算晚。因此，在做了一些研究后，我认为我的完美设置应该是：

• NUnit 2.5.x（我们已经与之绑定...所以是必需品）
• 与CruiseControl.Net集成（可以考虑其他选项，但只支持Git的免费工具）
• 与覆盖率工具集成（NCover，DotCover）会很好
• 集成运行shell命令的工具（用于JSLint和压缩工具等）

我缺少的是运行自动化构建的工具。我看了一下NAnt，但它对运行MSBuild（构建项目）的支持似乎相当过时（我们正在使用VS2010），而在我们的构建过程中利用解决方案文件将节省大量时间。我还看了看MSBuild（出于明显的原因），但我找到的运行NUnit测试的过程只支持2.4.x（MSBuild扩展项目）。

我很好奇其他人如何组织他们的持续构建系统。 NUnit相当受欢迎，所以我肯定不是唯一一个想知道这个问题的人。

- user131441

---

如果您想从解决方案文件构建，您可以始终使用devenv.exe，并使用/build和相关选项... http://codebetter.com/raymondlewallen/2005/07/20/using-devenv-at-the-command-prompt-to-build-projects/ - shelleybutterfly

这个方法可以实现...没错。但是我希望有一种在构建文件中看起来更清晰、更直观的方法，这样其他人在接手后也能更容易地管理它。 - user131441

不幸的是，我唯一参与的一个项目在我完成CI工作之前就被取消了，因此我无法设置持续构建。我曾经研究过这个问题，由于我们在开发过程中使用的解决方案已经进行了构建，我不想有两个单独的构建定义；我确实看了一下MSBuild，但在我们的情况下，我认为这样做并不值得。但是，听起来你比我更进一步了。 :) 我可以问一下你对使用devenv和.sln文件构建的不满是什么吗？一旦我掌握了/build选项，它对我来说似乎非常简单明了。 - shelleybutterfly

@shelleybutterfly - 尽管我是CLI的粉丝（更偏向于Unix，而不是Windows），但我认为大多数开发人员可能不太适应命令行。此外，如果我使用构建工具，我希望将所有内容保持在一个通用格式（XML）中，这样管理/操作构建脚本的人只需要学习一种格式。这也会使事情更易读，因此更易维护。 - user131441

哎呀，我从来没有完全设置好这个：`(，但我从未打算让开发人员做除了他们通常的IDE开发之外的任何事情，然后再将其检入Mercurial。我计划在本地提交后在开发人员框中进行自动测试运行（可配置），并在推送来自开发人员的内容时，在我们的发布点框上使用完整配置相同的设置。现在，我还在考虑自己编写工具来进行构建，以便获得所需的功能，而不是使用一个过于庞大或过于简单的大型工具。但这似乎值得一试。 - shelleybutterfly

Answer 1

我的第一个问题是，您将有多少个构建项目？ Teamcity Professional 免费提供每个服务器的20个构建配置，将使您的工作变得非常容易，并且具有内置的dotcover功能，设置起来非常简单，可以运行测试等。它是迄今为止最完整的CI服务器。 Jenkins 是紧随其后的竞争者，它是Hudson的分支，具有插件灵活性，可以完成几乎任何事情，这使其比Teamcity更加灵活，但其设置不太容易，代码覆盖率很难设置，并且存在一些烦人的缺陷，但完全免费。

除非您有一些非常强烈的原因使用CruiseControl.Net，否则不要费心，因为它在当时非常强大，但现在已经过时并且难以使用。

就构建设置而言，Teamcity和Jenkins都支持MSBuild、NAnt、Rake等，它们还支持多个构建步骤，就像在msbuild或Nant文件中所做的那样。我过去所做的就是使用.sln文件进行构建，使用内置的任务进行单元测试，然后使用内置的代码覆盖任务，然后使用另一个构建任务来推送文件。

我曾经使用过TeamCity、Jenkins、TFS，我也尝试使用CruiseControl.Net，但发现它非常笨拙。到目前为止，Teamcity是最好的，Jenkins紧随其后，即使有了TFS，我也不愿意使用。

如果您有任何问题，请随时与我联系。

- Bob The Janitor

---

所以，我想我的最大问题是，对于像 TeamCity Pro 这样的工具，我是否仍然需要一个自动化构建脚本（使用 NAnt 或 MSBuild），或者这些都会由 TeamCity 来处理？ - user131441

不需要使用MSBuild或nant如果您转移到TC的话。这取决于您想要扩展流程的程度。我认为你完全可以不用它们。 - James Woolfenden

知道这点很好。我预见到这个项目将有一个相当广泛的构建过程（至少对于发布版本），一个不受限制的自动化构建过程会很不错。然而，由于我们更需要一个（简单的）CI系统，因此这可能需要稍后再考虑。 - user131441

使用TeamCity和Jenkins，您可以设置构建步骤，避免使用MSBuild或NAnt。 - Bob The Janitor

Answer 2

您可以使用NAnt构建您的Visual Studio 2010解决方案。我经常这样做。我在这里提供了一个示例NAnt脚本，<msbuild>任务或使用NAnt的msbuild.exe？

- Babak Naffas

Answer 3

如果您只需要编译和运行测试，那么使用TeamCity是不会错的。它对NUnit/VS有很好的支持并内置了一堆报告。

如果您需要运行更复杂的构建脚本，我建议您使用FinalBuilder来创建构建脚本，并使用TeamCity命令运行器来执行该脚本。 通过将测试结果导入到TeamCity中，仍然可以获得报告，并且有一种简单的方法将FinalBuilder的构建状态输出到TeamCity中:

• 如何从FinalBuilder输出消息以被TeamCity捕获？
• 将构建状态从FinalBuilder输出到TeamCity

- Dror Helper

---

就像这篇帖子所暗示的那样，我真的不想在构建过程中花费太多的钱。因此，FinalBuilder SE每10个许可证售价839美元的事实已经对我不适用了。 - user131441