何时使用构建工具？
一个初学者问题，请耐心等待：我只是想知道在什么情况下应该使用像 nant 或 msbuild 这样的构建工具？ 我正在开发一个中型应用程序（.net 3.0），每个开发人员都在做他的工作并在他的机器上进行构建，检查他的代码更改到存储库中。 全部完成后，我将从存储库获取所有代码，在我的计算机上进行干净的构建，然后部署二进制文件。 只是出于好奇，构建工具在哪里？
A beginner question, bear with me: I'm just wondering under what circumstances one should use a build tool like nant or msbuild? I'm working on a medium sized application (.net 3.0), every developer is doing his work and builds on his machine checking his code changes into the repository as he goes. Once we're all done, I'll get all the code from the repository, make a clean build on my machine and we deploy the binaries. Just out of curiosity, where comes the build tool in?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
简短的回答是总是。
每个开发人员都应该在签入代码之前使用构建脚本进行构建。构建版本的人员应该使用构建脚本来构建版本。 您的构建机器人应该使用构建脚本来构建和测试已签入的代码。
这样做可以让所有开发人员、测试人员和构建机器人拥有一致、可重复的构建。 毕竟，F5 键不是构建过程。
The short answer is always.
Each developer should be building using the build script before checking code in. The people building the release should be using the build script to build the release. Your buildbots should be using the build script to build and test the code that's been checked in.
Doing this allows all the developers, testers and buildbots to have a consistent, repeatable build. After all, The F5 Key Is Not a Build Process.
听起来您正在使用 IDE 来进行构建。 它本质上是一个构建工具； 您已经在使用一个。 当您使用的工具更多地成为问题而不是解决方案时，您应该更换工具。
It sounds like you are using an IDE to do your build. It essentially is a build tool; you are already using one. You should switch tools when the one you are using becomes more of a problem than a solution.
当您的构建过程比一个命令长时，应该使用构建工具。 它应该用于将标准构建过程重新简化为一个命令。 如果您的构建过程比一个命令长，那么您就有可能因构建过程中执行的遗漏/重复/不正确的命令而出现错误。
A build tool should be used when your process for building becomes longer than one command. It should be used to get your standard build process back down into one command. If your build process is longer than one command, then you have the opportunity for errors to creep in from missed/duplicated/incorrect commands being done during a build.
我认为任何重要的应用程序都需要一个“构建工具”。 我们在我工作的地方使用“持续集成”这个术语。 有非常特殊的情况（例如：我正在构建一个示例应用程序来了解功能 X 的工作原理），但除此之外，您永远不会后悔拥有可靠的构建过程。
我想，如果开发团队由一个人组成......我仍然会建立一个构建系统，包括存储库、构建工具和多套测试。
是的，维护构建系统需要时间和金钱，但它会得到回报（我已经在一个由 6 名开发人员开始的项目上工作了 40 个月，现在包括大约 30 名开发人员；它确实为我们带来了很多回报在质量控制方面，越早发现质量问题，修复的成本就越低。
I think any non-trivial application needs a 'build tool'. We use the term Continuous Integration where I work. There are very exceptional cases (e.g.: I'm building a sample app to learn how feature X works), but aside from those, you'll never regret having a solid build process.
I guess that if the development team was made up of one person... I'd still set up a build system including a repository, a building tool, and multiple suites of tests.
Yes, maintaining the build system costs time and money, but it will pay off (I've been working for 40 months now on a project that started with 6 developers, and includes about 30 developers now; it did pay off for us a number of times) in terms of quality control, and the sooner quality issues are detected, the cheape they are to fix.
当您开始发布版本或构建超过一定数量的手动步骤时（您会注意到它开始变得烦人。）我写了一个旧的 有关此主题的博客条目，您可能会感兴趣。
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.
如果你想自动化任何事情，最好使用 nant/msbuild。 例如：
1. 办理登机手续
2. 构建
3. 测试和代码覆盖率
If you want to automate anything it's good to use nant/msbuild. For example:
1. check in
2. build
3. test and code coverage
您使用 Visual Studio 进行开发吗？ 在这种情况下，您已经在使用 msbuild，因为它是 Visual Studio 的底层构建引擎。 实际上，Visual Studio 项目文件只不过是一个 msbuild 脚本。
除此之外，您可以在专用的构建系统上使用构建引擎，这样您的二进制文件就可以在无人值守的情况下构建，并且无需安装 Visual Studio。 您还可以将其用于单元测试。
Are you developing with Visual Studio? In that case, you are already using msbuild, since that is the underlying build engine of Visual Studio. Actually, a Visual Studio project file is nothing more than a msbuild script.
Apart from that, you can use the build engine on a dedicated build system, so that your binaries can be built unattended and without having Visual Studio installed. You can also use that for unit-testing.
同意并扩展zacherates的答案......是的，你应该始终有一些可重复的构建过程。 虽然从技术上讲，Visual Studio 项目是 MSBuild 文件，但最好将“官方”构建过程与开发环境分开。
在我看来，无论团队有多大（或多小），这都是事实。 我在家里使用 NAnt 和 CruiseControl.NET，我倾向于从事临时项目和实验。 在工作中，我们使用类似的设置，但 NAnt 脚本的组合方式更加结构化。
这绝对值得您花时间研究一下。 这不是万能药，但它是准确了解哪个版本发布时间以及发布内容的最佳实践。 能够识别编译的代码是故障排除战斗的一半！ :)
Agreeing with and expanding on zacherates' answer ... Yes, you should always have some repeatable build process. While technically Visual Studio projects are MSBuild files, it's better to have the "official" build process be separate of the development environment.
In my mind, this is true no matter how big (or small) the team is. I use NAnt and CruiseControl.NET at home, where all I tend to work on are scratch projects and experiments. At work, we use a similar setup, but a bit more structured in how the NAnt scripts are put together.
It's definitely worth your time to look into it. It's not a cure-all, but it is a best practice for knowing exactly which build was released when, and what's in the wild. Being able to identify your compiled code is half the troubleshooting battle! :)