基于任务的构建系统

报告问题 查看来源 每晚 · 7.4。 ，了解所有最新动态。 7.3 · 7.2 · 7.1 · 7.0 · 6.5

本页介绍了基于任务的构建系统、它们的工作原理以及基于任务的系统可能出现的一些复杂问题。在 Shell 脚本之后 基于任务的构建系统是构建领域的下一个逻辑发展。

了解基于任务的构建系统

在基于任务的构建系统中，基本的工作单元是任务。每个 任务是一个脚本，可执行任何种类的逻辑，而任务指定 它们作为依赖项必须在它们之前运行。正在使用的大多数主要构建系统 例如 Ant、Maven、Gradle、Grunt 和 Rake，它们都是基于任务的。而不是 Shell 脚本，大多数现代构建系统都需要工程师创建构建文件 说明如何进行构建。

请参考 Ant 手册中的以下示例：

<project name="MyProject" default="dist" basedir=".">
   <description>
     simple example build file
   </description>
   <!-- set global properties for this build -->
   <property name="src" location="src"/>
   <property name="build" location="build"/>
   <property name="dist" location="dist"/>

   <target name="init">
     <!-- Create the time stamp -->
     <tstamp/>
     <!-- Create the build directory structure used by compile -->
     <mkdir dir="${build}"/>
   </target>
   <target name="compile" depends="init"
       description="compile the source">
     <!-- Compile the Java code from ${src} into ${build} -->
     <javac srcdir="${src}" destdir="${build}"/>
   </target>
   <target name="dist" depends="compile"
       description="generate the distribution">
     <!-- Create the distribution directory -->
     <mkdir dir="${dist}/lib"/>
     <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
     <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
   </target>
   <target name="clean"
       description="clean up">
     <!-- Delete the ${build} and ${dist} directory trees -->
     <delete dir="${build}"/>
     <delete dir="${dist}"/>
   </target>
</project>

buildfile 采用 XML 编写，用于定义与 build 相关的一些简单元数据以及任务列表（XML 中的 <target> 标记）。（Ant 使用 target 表示任务，并使用任务一词来指代 命令。）每个任务都会执行 Ant 定义的一系列可能的命令，其中包括创建和删除目录、运行 javac 和创建 JAR 文件。这组命令可通过用户提供 涵盖各种逻辑的插件每个任务还可以定义 依赖项。这些依赖项会形成一个非循环图，如图 1 所示。

显示依赖关系的亚克力图

图 1. 显示依赖项的无环图

用户通过向 Ant 的命令行工具提供任务来执行构建。例如，当用户输入 ant dist 时，Ant 会执行以下步骤：

  1. 加载当前目录中名为 build.xml 的文件，并对其进行解析，以创建图 1 所示的图结构。
  2. 查找命令行上提供的名为 dist 的任务，并发现它依赖于名为 compile 的任务。
  3. 查找名为 compile 的任务，并发现它有一个依赖项 名为 init 的任务。
  4. 查找名为 init 的任务，并发现它没有依赖项。
  5. 执行 init 任务中定义的命令。
  6. 在 compile 任务的所有依赖项都已运行的情况下，执行 compile 任务中定义的命令。
  7. 执行 dist 任务中定义的命令，前提是所有这些命令 任务依赖项已运行。

最后，Ant 在运行 dist 任务时执行的代码等同于以下 shell 脚本：

./createTimestamp.sh
mkdir build/
javac src/* -d build/
mkdir -p dist/lib/
jar cf dist/lib/MyProject-$(date --iso-8601).jar build/*

删除语法后，buildfile 和 build 脚本实际上 没有太大区别但我们已经从中获益良多。我们可以在其他目录中创建新的 buildfile 并将它们关联起来。我们可以轻松 以任意且复杂的方式添加依赖于现有任务的新任务。周三 只需将单个任务的名称传递给 ant 命令行工具，它 决定需要运行的所有内容

Ant 是一款旧软件，最初发布于 2000 年。在过去几年中，Maven 和 Gradle 等其他工具在 Ant 的基础上不断改进，并通过添加自动管理外部依赖项和无任何 XML 的更简洁语法等功能，从根本上取代了 Ant。但这些新技术的性质 系统则保持不变：这些系统允许工程师以 原则化的模块化任务，并提供用于执行这些任务的工具 以及管理它们之间的依赖关系

基于任务的构建系统的缺点

由于这些工具本质上允许工程师将任何脚本定义为任务，因此它们非常强大，可让您通过它们执行几乎所有能想象到的操作。但这种能力也存在缺点，基于任务的构建系统 使其构建脚本变得越来越复杂。此类系统的问题在于，它们最终会向工程师提供过多权限，而向系统提供的权限不足。由于系统不知道脚本在执行什么操作，因此在调度和执行 build 步骤时必须非常保守，这会导致性能下降。而且系统无法 确认每个脚本都执行了它应有的操作， 并最终成为另一个需要调试的问题。

难以并行执行构建步骤

现代开发工作站非常强大，其多个核心能够并行执行多个构建步骤。但是，基于任务的系统通常无法并行执行任务，即使看起来应该可以并行执行也是如此。假设任务 A 依赖于任务 B 和 C。因为任务 B 和任务 C 不相互依赖，同时运行它们是否安全？ 系统是否能够更快地完成任务 A？也许，如果他们不碰任何东西 相同的资源但也许不是这样，也许这两个任务都使用相同的文件来跟踪状态，同时运行它们会导致冲突。我们没有 但系统通常知道这些冲突， （会导致罕见但非常难以调试的构建问题），或者 将整个构建限制为在单个进程的单个线程上运行。 这可能是强大的开发机器的巨大浪费， 排除将 build 分发到多台机器的可能性。

难以执行增量构建

借助良好的构建系统，工程师可以执行可靠的增量构建，这样一来，只需进行一项小更改，就无需从头开始重新构建整个代码库。如果构建系统运行缓慢且无法 基于上述原因并行构建步骤。但遗憾的是 基于任务的构建系统在这方面也有困难。由于任务可以执行任何操作，因此通常无法检查它们是否已完成。多项任务 只需获取一组源文件并运行编译器 即可创建一组 binaries;因此如果底层源文件存在 没有任何变化但如果没有额外信息，系统便无法显示 任务下载的文件可能已更改 写入一个时间戳，该时间戳在每次运行时可能都有所不同。为了保证 正确性，系统通常必须在每次构建期间重新运行每个任务。某些构建系统会尝试通过让工程师指定需要重新运行任务的条件来启用增量构建。有时这样做是可行的 这往往比表面上看起来要复杂得多。例如，在语言中 就像允许其他文件直接包含文件的 C++ 一样， 无法确定必须监视更改的整组文件 而无需解析输入源。工程师最终往往会采取捷径，而这些捷径可能会导致罕见且令人沮丧的问题，即重复使用任务结果，即使不应这样做。如果这种情况经常发生，工程师会 养成在每次构建前都进行清理的习惯，以获得全新状态， 完全违背了在首次测试阶段进行增量构建的目的。 位置。弄清楚何时需要重新运行某个任务非常微妙， 让机器比人类更好地处理工作。

难以维护和调试脚本

最后，基于任务的构建系统施加的构建脚本通常只是 也很难处理虽然构建脚本通常不太受审核，但它们与要构建的系统一样是代码，并且很容易隐藏 bug。以下是使用基于任务的构建系统时非常常见的一些 bug 示例：

  • 任务 A 依赖任务 B 来生成特定文件作为输出。所有者 的任务 B 没有意识到其他任务依赖于该任务，因此将其更改为 在其他位置生成输出只有当有人尝试运行任务 A 并发现其失败时，才能检测到此问题。
  • 任务 A 依赖于任务 B，而任务 B 依赖于任务 C，而任务 C 会生成 输出特定文件作为任务 A 所需的输出。任务 B 的所有者决定不再依赖于任务 C，这会导致任务 A 失败，即使任务 B 根本不关心任务 C 也是如此！
  • 新任务的开发者不小心对 例如工具的位置或 特定环境变量任务在其机器上可以正常运行，但每当其他开发者尝试运行时都会失败。
  • 任务包含非确定性组件，例如从互联网下载文件或向 build 添加时间戳。现在，用户每次运行 build 时都可能会得到不同的结果，这意味着工程师不一定能重现和修复彼此的失败问题，也无法修复自动化 build 系统上发生的失败问题。
  • 具有多个依赖项的任务可能会创建竞态条件。如果任务 A 同时依赖于任务 B 和任务 C，并且任务 B 和任务 C 都修改了同一文件，那么任务 A 会获得不同的结果，具体取决于任务 B 和任务 C 中哪个任务先完成。

没有通用的方法来解决这些性能、正确性或 基于任务的框架中的可维护性问题。只要工程师可以编写在 build 期间运行的任意代码，系统就无法获得足够的信息，无法始终能够快速且正确地运行 build。要解决这个问题，我们需要节省一些能源， 把它放回系统手里，重新概念 而不是运行中的任务，而是生成工件。

这种方法催生了 Blaze 和 Bazel 等基于工件的构建系统。