何时使用构建工具？

Question

一个初学者的问题，忍耐着我：我只是想知道在什么情况下应该使用像nant或msbuild这样的构建工具？我正在开发一个中等规模的应用程序（.net 3.0），每个开发人员都在做他的工作，并在他的机器上构建，随时检查他的代码更改到存储库中。一旦我们完成了，我将从存储库获取所有代码，在我的机器上构建一个干净的构建，并部署二进制文件。出于好奇，这里的构建工具来自哪里？

Answer 1

简短的回答总是。

在开始检查代码之前，每个开发人员都应该使用构建脚本进行构建。构建版本的人员应该使用构建脚本构建版本。您的buildbots应该使用构建脚本来构建和测试已签入的代码。

这样做可以让所有开发人员，测试人员和构建人员拥有一致的可重复构建。毕竟，The F5 Key Is Not a Build Process。

Answer 2

如果你想自动化任何东西，最好使用nant/msbuild。例如： 1.检查 2.构建 3.测试和代码覆盖率

Answer 3

你使用Visual Studio开发？在这种情况下，您已经使用了msbuild，因为这是Visual Studio的基础构建引擎。实际上，Visual Studio项目文件不过是一个msbuild脚本。

除此之外，您可以在专用的构建系统上使用构建引擎，以便可以无人值守地构建二进制文件，而无需安装Visual Studio。你也可以用它来进行单元测试。

Answer 4

我认为任何不平凡的应用程序都需要一个“构建工具”。我们在工作中使用术语“持续集成”。有非常特殊的情况（例如：我正在构建一个示例应用程序以了解功能X的工作原理），但除此之外，您永远不会后悔拥有坚实的构建过程。

我想，如果开发团队是由一个人组成的......我会仍然建立一个构建系统，包括存储库，建筑工具和多套测试。 是的，维护构建系统花费的时间和金钱，但它会得到回报（我已经工作了40个月，现在已经开始了6个开发人员的项目，现在包括大约30个开发人员;它确实为我们带来了回报在质量控制方面的次数），并且发现质量问题越早，他们将要解决的问题。

Answer 5

当您的构建过程比一个命令长时，应该使用构建工具。它应该被用来让你的标准构建过程回到一个命令。如果你的构建过程比一个命令长，那么你就有机会在构建过程中从错过/重复/不正确的命令中产生错误。

Answer 6

同意并扩大zacherates的答案......是的，你应该总是有一些可重复的构建过程。虽然技术上Visual Studio项目是MSBuild文件，但最好是将“官方”构建过程与开发环境分开。

在我看来，无论团队多大（或小），这都是事实。我使用NAnt和CruiseControl.NET 在家，在那里我倾向于工作的是临时项目和实验。在工作中，我们使用了类似的设置，但在NAnt脚本放在一起的结构方面更加结构化。

绝对值得你花时间去研究它。这不是万能的，但这是确切知道哪个版本在什么时候发布以及什么是发布的最佳实践。能够识别您的编译代码是故障排除战斗的一半！ :)

Answer 7

这听起来像你正在使用IDE来做你的构建。它本质上是一个构建工具;你已经在使用一个。当你使用的工具比解决方案更成为问题时，你应该切换工具。

Answer 8

当你开始做发布或者当你的构建超过了一定数量的手动步骤时（你会注意到它开始变得讨厌）。我已经写了一个关于这个话题的旧的blog entry，你可能会感兴趣。