什么是构建工具？

构建工具通常在命令行上运行，或者在 IDE 内部，或者完全独立于 IDE。

其思想是将编译和打包代码的工作与创建、调试等分离开来。

生成工具可以在命令上运行，也可以在 IDE 内运行，这两者都是由您触发的。在将代码从存储库检查到干净的构建机器上之后，持续集成工具也可以使用它们。

Make 是在构建 C/C + + 的 * nix 环境中使用的早期命令工具。

作为 Java 开发人员，最流行的构建工具是 Ant 和 Maven。两者都可以在 IntelliJ、 Eclipse 或 NetBeans 等 IDE 中运行。它们也可以被像 Cruise Control 或 Hudson 这样的持续集成工具使用。

您一直在使用它们-IDE 是一个构建工具。对于命令行，可以使用 make之类的命令。

人们使用命令行工具来完成每晚的构建工作——因此，早上醒来的时候，程序员意识到他一直在修改的库的最新版本的代码不能工作了！

构建工具是管理和组织构建的工具，在有许多项目的环境中非常重要，特别是在它们相互连接的情况下。它们的作用是确保不同的人在不同的项目中工作，它们不会破坏任何东西。为了确保当你做出改变的时候，他们也不会打破任何东西。

你之前没有听说过他们的原因是你以前没有在商业环境中工作过。在商业环境中可能会遇到很多您可能没有遇到过的东西，特别是如果您在软件公司工作的话。

正如其他人所说，你一直在使用它们，但是，你没有必要去考虑它们，因为你可能一直在以一种不同于通常的商业工作方式的方式工作。

构建工具通常是将源代码转换为二进制文件——它组织源代码、设置编译标志、管理依赖关系... ... 其中一些还与运行单元测试、进行静态分析、生成文档集成。

Eclipse 或 Visual Studio 也是构建系统(但更多的是 IDE) ，对于 Visual Studio 来说，它是解析可视化工作室项目文件的底层 msbuild。

所有构建系统的起源看起来像著名的“ make”。

有不同语言的构建系统:

1. C + + : make，cmake，premake
2. Java: ant + ivy，maven，gradle
3. C # : msbuild

通常，构建系统要么使用特定于属性域的语言(make、 cmake) ，要么使用 xml (ant、 maven、 msbuild)来指定构建。目前的趋势是使用真正的脚本语言来编写构建脚本，比如用 lua 来编写 premake，用 groovy 来编写 gradle，使用脚本的优势在于它更加灵活，并且允许你编写一组标准的 API (构建 DSL)。

什么是构建工具？

构建工具是自动创建可执行文件的程序 来自源代码的应用程序(例如，用于 Android 应用程序的 .apk) 将代码编译、链接和打包成一个可用的或 可执行文件可执行文件。

基本上组建自动化就是编写脚本或者自动化一个 各种各样的任务，软件开发人员在他们的日常工作 活动包括:

1. 下载依赖项。
2. 将源代码编译成二进制代码。
3. 包装那个二进制代码。
4. 做测试。
5. 部署到生产系统。

我们为什么要使用构建工具或组建自动化？

在小型项目中，开发人员通常会手动调用构建 过程。这是不实际的大型项目，这是非常 很难跟踪什么需要建立，在什么顺序和 构建过程中存在哪些依赖项 自动化工具允许构建过程更加一致。

可用的各种构建工具(只命名少数) :

1. 对于 java-Ant，Maven，Gradle。
2. 用于.NET 框架-NAnt
3. C #-MsBuild.

如需进一步阅读，请参阅以下连结:

1. 组建自动化

2. 构建自动化软件列表

谢谢。

Build Process 是使用某些生成工具和创建生成(它们是项目的可执行版本)来编译源代码以防止任何错误的过程。我们(主要是开发人员)在源代码中进行一些修改，并签入代码以发生构建过程。在构建过程之后，它会给出两个结果: 1. 要么构建 PASSES，然后得到项目的可执行版本(构建已准备就绪)。 2. 它失败了，你得到了某些错误，构建没有被创建。

有不同类型的构建过程，比如: 1. 每夜建造 门式结构 3. 持续集成构建等。

构建工具帮助并自动化创建构建的过程。

* So in Short Build 是一个预发布格式的软件版本，开发人员或开发团队通过持续监控他们的产品并在开发过程的早期解决任何问题来获得对产品最终结果的信心。 *

这些是可以完成构建的不同类型的过程。

1.持续集成构建: 在这里，主要是开发人员签入他们的代码，并且在他们签入之后，一个构建启动器会为最近的更改进行构建，所以我们应该知道开发人员所做的更改在签入完成之后是否有效。对于较小的项目或项目的组件，这是首选的。如果有多个团队与项目相关联，或者有一个很大的。在同一个项目中工作的开发人员，这个场景变得很难处理，就好像没有。检入和构建在某些时候失败很难追踪所有的破坏是因为一个问题还是因为多个问题，所以如果旧的问题没有得到适当的解决，那么追踪在更改之后发生的后续缺陷就会变得非常困难。这些构建的主要好处是，我们可以知道某个签入是否成功。

2.有门限的签入构建: 在这种类型的签入构建中，在签入完成后立即启动，并保持搁置集中的更改。在这种情况下，如果构建成功而搁置集签入未提交，则不会将其提交到 TeamFoundationServer。由于只有成功的签入才被允许提交，因此从持续集成构建中可以看到一个稍微好一点的画面。

3.夜间构建: 这也称为计划构建。在这种情况下，我们将生成计划为特定时间运行，以便生成更改。上次构建后的所有未提交更改都是在此构建过程中构建的。当我们想要多次签入代码，但是不想每次签入代码时都进行构建时，我们就可以实现这一点，这样我们就可以有一个固定的时间或周期来启动构建以构建签入代码。

有关这些构建的详细信息可以在下面的位置找到。

生成中的门限检查

持续集成构建

夜间建筑

“ ... ... 很难跟踪需要构建的内容”-构建工具对此毫无帮助。你需要知道你想要建造什么。(引自 Ritesh Guns 的回答)

“我听说它们几乎被用于所有类型的现实世界开发”——出于某种原因，软件开发人员喜欢在大公司工作。他们似乎对在那里工作的每个人都有更不明确的工作指示。

“为什么在过去的四年里我从来不需要它们”。也许是因为你是一个熟练的程序员。

修多，超能力者。我认为构建工具根本不能提供任何真正的好处。它只是增加了一种安全感，这种安全感来自于糟糕的公司实践、缺乏方向——糟糕的软件架构领导导力导致对项目的实际了解不足。您永远不应该在您的项目中使用构建工具(用于测试)。在缺乏软件项目知识的情况下进行随机测试根本没有任何帮助。

您永远不应该在不知道项目的用途以及它将如何与其他组件一起工作的情况下向项目中添加内容。组件可以是功能独立的，但不能一起工作。(这是我所承担的软件架构师的责任)。

如果将4-5个组件添加到项目中会怎样。你添加了第六个组件。再加上第一个添加的组件，它可能会把一切都搞砸。没有自动装置可以帮助检测到这一点。

没有捷径，只有思考，思考，思考。

然后是从存储库自动下载。你为什么要这么做？您需要知道您下载了什么，向项目中添加了什么。如何检测存储库版本中的更改？你需要知道。你不能“自动”任何东西。

如果我们测试自行车和婴儿车蒙上眼睛，用棍子随意敲打。这似乎就是构建工具测试的想法。

对不起，没有捷径 Https://en.wikipedia.org/wiki/scientific_method 还有 Https://en.wikipedia.org/wiki/analysis