在过去的4年中，我一直在使用Eclipse（用于Java）和Visual Studio Express（用于C＃）进行编程。提到的IDE似乎总是提供程序员可能要求的每个工具（当然与编程有关）。
最近我听说过一种叫做“构建工具”的东西。我听说他们几乎被用于各种现实世界的发展。它们究竟是什么？他们设计要解决哪些问题？为什么我在过去的四年里从未需要它们？它们是一种命令行剥离IDE吗？
答案 0 :(得分：98)
什么是构建工具？
构建工具是自动创建可执行文件的程序 来自源代码的应用程序（例如.apk for android app）。建造 将代码编译，链接和打包成可用的或 可执行形式。
基本上，构建自动化是脚本或自动化的行为 软件开发人员在日常工作中执行的各种任务 活动如：
- 下载依赖项。
- 将源代码编译为二进制代码。
- 打包二进制代码。
- 运行测试。
- 部署到生产系统。
为什么我们使用构建工具或构建自动化？
在小型项目中，开发人员通常会手动调用构建 处理。对于规模较大的项目来说，这是不切实际的 很难跟踪需要建立什么，以什么顺序和 构建过程中存在哪些依赖关系。用一个 自动化工具允许构建过程更加一致。
提供各种构建工具（仅命名少数）：
- 对于java - Ant，Maven，Gradle。
- 对于.NET框架 - NAnt
- c＃ - MsBuild。
如需进一步阅读，请参阅以下链接：
感谢。
答案 1 :(得分：17)
构建工具是管理和组织构建的工具，在有许多项目的环境中非常重要，特别是在它们相互连接的情况下。它们有助于确保各种各样的人在各种项目中工作，他们不会破坏任何东西。并且为了确保在进行更改时，它们也不会破坏任何内容。
之前没有听说过的原因是你之前没有在商业环境中工作过。在商业环境中，你可能没有遇到很多东西，特别是如果你在软件公司工作。
正如其他人所说的，你一直在使用它们，但是，你没有必要考虑它们，因为你可能以不同的方式工作，而不是通常的商业工作方式。
答案 2 :(得分：10)
构建工具通常在命令行上运行，可以在IDE内部运行，也可以与IDE完全分开。
我们的想法是将编译和打包代码的工作与创建，调试等分开。
构建工具可以在命令上运行，也可以在IDE内运行，两者都由您触发。在将代码从存储库检查到干净的构建机器之后，它们也可以由持续集成工具使用。
make是* nix环境中用于构建C / C ++的早期命令工具。
作为Java开发人员，最流行的构建工具是Ant和Maven。两者都可以在IntelliJ，Eclipse或NetBeans等IDE中运行。它们也可以被Cruise Control或Hudson等持续集成工具使用。
答案 3 :(得分：4)
构建工具通常是将源代码转换为二进制文件 - 它组织源代码，设置编译标记，管理依赖项......其中一些还集成了运行单元测试，静态分析，生成文档。
Eclipse或Visual Studio也是构建系统（但更多是IDE），对于visual studio，底层的msbuild可以解析Visual Studio项目文件。
所有构建系统的起源似乎都是着名的'make'。
有不同语言的构建系统：
通常，使用专有域特定语言（make，cmake）或xml（ant，maven，msbuild）构建系统来指定构建。目前的趋势是使用真正的脚本语言来编写构建脚本，比如lua用于premake，而groovy用于gradle，使用脚本的优点是它更灵活，并且还允许你提出一套标准API（作为构建DSL）。
答案 4 :(得分：1)
构建过程是使用一些构建工具和创建构建（这是项目的可执行版本）来编译任何错误的源代码的过程。我们（主要是开发人员）在源代码中进行一些修改并签入构建过程的代码。在构建过程之后，它给出了两个结果： 1.构建PASSES并获得项目的可执行版本（Build已准备就绪）。 2.它失败并且您得到某些错误并且未创建构建。
有不同类型的构建过程，如： 1.每晚建造 2.门控构建 3.持续集成构建等。
构建工具可帮助并自动化创建构建的过程。
* 因此，Short Build是开发人员或开发团队使用的预发布格式的软件版本，通过持续监控他们的产品并解决任何问题来获得对其产品最终结果的信心在开发过程的早期。 *
答案 5 :(得分：1)
这些是您可以通过它们完成构建的不同类型的过程。
<强> 1。持续集成构建：在这主要是开发人员签入他们的代码并在他们签入后立即启动构建最近的更改，因此我们应该知道开发人员所做的更改是否有效办理登机手续。对于较小的项目或项目组件，这是首选。如果多个团队与项目相关联或者有大量的团队。在同一个项目上工作的开发人员很难处理这种情况，好像有“＆nbsp;”没有。签到和构建失败在某些点上变得非常难以追踪是否由于一个问题或多个问题而发生了所有破损，因此如果旧问题没有得到正确解决而不是很难追溯到后来这种变化后发生的缺陷。这些构建的主要好处是我们可以了解特定的签到是否成功。
<强> 2。门禁登记版本：在这种类型的检查中，在签入完成后立即启动，并保持搁置集中的更改。在这种情况下，如果构建成功，则shelve-set签入将被提交，否则将不会提交到Team Foundation Server。这为持续集成构建提供了更好的图片，因为只有成功的签到才能被提交。
第3。每夜构建：这也称为预定构建。在这种情况下，我们将构建计划运行特定时间以构建更改。上次构建中之前的所有未提交的更改都是在此构建过程中构建的。当我们想要多次签入但不希望每次签入代码时都需要构建时，我们就可以实现这一点，这样我们就可以有一个固定的时间或周期来启动构建以构建签入的代码。 / p>
有关这些版本的更多详细信息，请访问以下位置。
答案 6 :(得分：0)
您一直在使用它们 - IDE是一个构建工具。对于命令行，您可以使用make之类的内容。
人们使用命令行工具来完成夜间构建 - 所以在早上宿醉时，程序员已经意识到他一直在使用最新版本的库来编写代码不起作用！
答案 7 :(得分：-1)
“......很难跟踪需要构建的内容” - 构建工具并没有帮助解决这些问题。你需要知道你想要建立什么。 （引自Ritesh Gun的回答）
“我听说它们几乎用于各种现实世界的开发” - 出于某种原因，软件开发人员喜欢在大公司工作。他们似乎对在那里工作的每个人都有更明确的工作指令。
“过去四年我怎么也不需要它们”。可能是因为你是一名熟练的程序员。
Pseudo，meta。我认为构建工具根本不能提供任何真正的实惠。只是在那里增加了由于糟糕的公司实践，缺乏方向而产生的安全感 - 糟糕的软件架构领导导致对项目的不良实际知识。您永远不必在项目中使用构建工具（用于测试）。在缺乏软件项目知识的情况下进行随机测试并不能提供任何帮助。
你永远不应该在不了解项目目的的情况下向项目添加内容，以及它如何与其他组件一起使用。组件可以是功能分离的，但不能一起工作。 （这是我假设的软件架构师的责任。）
如果将4-5个组件添加到项目中，该怎么办？您添加第6个组件。与第一个添加的组件一起，它可能搞砸了一切。没有自动会有助于检测到它。
除了思考思考之外没有捷径。
然后从存储库中自动下载。你为什么要这样做？您需要知道下载的内容，添加到项目中的内容。如何检测存储库版本的更改？你得知道。你不能“自动”任何东西。
如果我们试着用棍子蒙住眼睛测试自行车和婴儿运输，然后只是随意地用它来敲打。这似乎是构建工具测试的想法。
对不起没有捷径 https://en.wikipedia.org/wiki/Scientific_method 和 https://en.wikipedia.org/wiki/Analysis