浅论管理构建依赖

管理真正构建是非常复杂的，但至少我们学会了如何安装和启动Jenkins。中培专家龚老师指出，如果在安装fortune程序时遇上了麻烦，你还会对持续集成服务器的阴暗面有一个初步的了解：管理构建依赖。

有些构建系统，例如Maven工具，它的POM文件描述了所需的构建依赖，这一点很不错。如果这些依赖在构建服务器里还不存在，Maven会自动下载它们。JavaScript的构建工具Grunt也很类似，有一个构建描述文件包含了构建所需要的依赖。Golang为了完成构建，甚至还可以包含GitHub库的链接。

C和C++构建存在着不同的挑战。许多项目使用GNU的Autotools，它的Autoconf并不描述需要的依赖，而是适配主机上可用的依赖。所以，为了构建文本编辑器Emacs，你需要先运行配置脚本来查明构建系统上潜在的诸多依赖中哪一个是可用的。

让软件在许多不同的系统配置上都可用是一个很有用的功能，因为我们并不总是想让建基于重量级的配置。在这种情况下，我们需要确定哪个功能百分百终将可用。我们当然不想因为在产品环境上遗漏功能而大吃一惊。

RPM( Red Hat Package Manager)系统，用于基于Red Hat的各种系统，给这个问题提供了一个解决方案。RPM系统的核心是一个称为spec文件的构件描述文件。它列出了需要成功构建所需的构建依赖、构建命令，还有使用的配置选项。因为一个spec文件本质上是一个基于宏的shell脚本，所以你可以用它来构建许多类型的软件。砌，M系统也认为构建源代码应该从零开始。可以用构建之前通过spec文件给源代码打包的方式适配源代码。

最终工件

在使用RPM系统完成构建之后，你得到了一个RPM文件，这种类型可以很方便地给Red Hat系列操作系统部署工件。对于Debian系的发行版来说，你得到的是个.deb文件。  Maven构建的最终结果一般是企业级档案，简称EAR文件。它包含着Java企业级应用。

它是我们之后要部署到生产服务器上的最终部署工件。

尽管如此，即使在构建工件的时候，我们也需要理解如何部署它们。现在，我们将要使用以下的经验法则：操作系统级别的包优于特定的包。这是我的个人喜好，其他人可能不同意。

让我们简要地讨论一下这个经验法则的背景和其他的方案。

作为一个实际的例子，让我们考虑Java EAR的部署。通常，我们有几种方法来实现。

想了解更多IT资讯，请访问中培教育官网：中培教育