一个初学者的问题，请耐心等待：我只是想知道在什么情况下应该使用像 nant 或 msbuild 这样的构建工具？我正在开发一个中型应用程序（.net 3.0），每个开发人员都在做他的工作，并在他的机器上构建，检查他的代码更改到存储库中。一旦我们都完成了，我将从存储库中获取所有代码，在我的机器上进行干净的构建，然后部署二进制文件。只是出于好奇，构建工具在哪里？
Matthias
问问题
2244 次
8 回答
15
简短的回答总是。
每个开发人员都应该在签入代码之前使用构建脚本进行构建。构建版本的人员应该使用构建脚本来构建版本。您的构建机器人应该使用构建脚本来构建和测试已签入的代码。
这样做可以让所有开发人员、测试人员和构建机器人拥有一致的、可重复的构建。毕竟，F5 键不是构建过程。
于 2008-10-14T12:58:16.883 回答
6
听起来您正在使用 IDE 进行构建。它本质上是一个构建工具；您已经在使用一个。当您使用的工具成为问题而非解决方案时，您应该切换工具。
于 2008-10-14T13:11:54.687 回答
4
当您的构建过程超过一个命令时，应使用构建工具。它应该用于将您的标准构建过程归结为一个命令。如果您的构建过程比一个命令长，那么您就有机会从构建期间执行的错过/重复/不正确的命令中爬出错误。
于 2008-10-14T13:01:18.840 回答
2
我认为任何重要的应用程序都需要一个“构建工具”。我们在我工作的地方使用术语持续集成。有非常特殊的情况（例如：我正在构建一个示例应用程序来了解功能 X 的工作原理），但除此之外，您永远不会后悔拥有一个可靠的构建过程。
我想如果开发团队由一个人组成……我仍然会建立一个构建系统，包括一个存储库、一个构建工具和多套测试。是的，维护构建系统需要时间和金钱，但它会得到回报（我已经为一个由 6 个开发人员开始的项目工作了 40 个月，现在包括大约 30 个开发人员；它确实为我们带来了很多回报次）在质量控制方面，越早发现质量问题，解决问题的成本就越低。
于 2008-10-14T13:01:05.363 回答
2
When you start doing releases or when your build exceeds certain number of manual steps (you'll notice when it starts getting annoying.) I've written an old blog entry on this topic which you might find interesting.
于 2008-10-14T14:04:27.810 回答
0
如果你想自动化任何事情，最好使用 nant/msbuild。例如：1.签入 2.构建 3.测试和代码覆盖率
于 2008-10-14T12:59:55.520 回答
0
您是否使用 Visual Studio 进行开发？在这种情况下，您已经在使用 msbuild，因为它是 Visual Studio 的底层构建引擎。实际上，Visual Studio 项目文件只不过是一个 msbuild 脚本。
除此之外，您可以在专用的构建系统上使用构建引擎，这样您的二进制文件就可以在无人看管的情况下构建，而无需安装 Visual Studio。您也可以将其用于单元测试。
于 2008-10-14T13:00:04.553 回答
0
同意并扩展 zacherates 的回答……是的，您应该始终有一些可重复的构建过程。虽然从技术上讲，Visual Studio 项目是 MSBuild 文件，但最好将“官方”构建过程与开发环境分开。
在我看来，无论团队有多大（或多小）都是如此。我在家里使用 NAnt 和 CruiseControl.NET ，我倾向于从事的只是临时项目和实验。在工作中，我们使用类似的设置，但在 NAnt 脚本的组合方式上更加结构化。
绝对值得您花时间研究它。这不是万灵药，但它是准确了解哪个版本何时发布以及什么是野外发布的最佳实践。能够识别您的编译代码是故障排除战的一半！:)
于 2008-10-14T13:04:31.707 回答