TeamCity构建依赖项

介绍

构建依存关系的主题既不重要也不是次要的。各种构建工具从不同的角度处理此主题，从而提供各种解决方案，每种解决方案都有其优点和缺点。

熟悉发行版和快照依赖项的Maven和Gradle用户可能不了解TeamCity快照依赖项，或者认为他们与Maven相关（这是不正确的）。熟悉工件和快照依赖关系的TeamCity用户可能不知道，除了TeamCity提供的插件之外，添加Artifactory插件还使他们能够使用工件并建立依赖关系。

上面提到的某些名称似乎建立得不够充分，而其他一些则可能需要讨论其使用方式。考虑到这一点，我决定在自己的博客文章中探索每种解决方案，并设定了提供足够信息的目标，以便人们可以选择最有效的方法。

第一篇文章探讨了 Maven快照和发行版的依赖关系。这是第二篇文章，其中介绍了TeamCity提供的工件和快照的依赖关系，而第三篇也是最后一部分将介绍TeamCity Artifactory插件提供的工件和构建的依赖关系。

非Maven依赖项

虽然基于Java的Maven依赖关系管理和工件存储库在Java中非常普遍并且分布广泛，但是在某些情况下，您仍然可能发现它们不足或不足以满足您的需求。首先，您可能没有使用Java进行开发，或者您的构建工具可能未提供与Maven存储库的内置集成，就像Ant （或它的Gant和NAnt衍生产品）， SCons ， Rake或MSBuild一样。其次，快照Maven依赖项提供了自己的挑战，这在上一篇博客文章中已涉及到，这使得更难确保在构建链中使用正确的快照依赖项。

为了解决这些情况，TeamCity提供了两种方法来连接相关的构建配置及其结果：工件和快照相关性。

TeamCity神器依赖项

TeamCity中工件依赖的想法非常简单：在当前版本开始之前，下载另一版本生成的工件。将工件下载到指定的文件夹（默认情况下为checkout目录）之后，您的构建脚本可以使用它们来实现其目标。您可以在TeamCity文档中找到配置详细信息。

自然，此方案不适用于具有自动依赖项管理的构建工具，但它与接受或期望本地路径（相对于checkout目录）的构建或shell脚本一起使用时效果很好。请注意，复制不仅适用于生成的生成二进制文件，而且还适用于任何类型的二进制文件或文本文件，例如上面的屏幕截图所示的TeamCity覆盖率报告。

关于指定工件依赖项有一个重要的细节，即“从中获取工件”配置，在此配置中，您应指定应从中获取文件的构建类型。该字段的可能值为“最后成功”，“完成”，“固定”或“标记构建”，以及构建号或“从同一链构建”。尽管大多数值对于理解“上一次成功构建”是默认且普遍适用的选项来说应该是微不足道的，但“相同链”构建的定义与TeamCity 快照依赖关系直接相关。

TeamCity快照依赖项

想象一下一个整体的多步骤构建过程（构建，测试，打包，部署），您决定将其拆分为多个较小的构建，依次调用它们，形成执行链。这样做可以使每个步骤分别配置或触发，并并行运行某些步骤，以加快流程速度（例如执行测试或构建独立的组件）。最重要的是，它使整体维护非常容易。但是，这样做时，即使在链步骤运行的同时进行了新的提交，也需要确保每个链步骤都使用从VCS提取的相同的一致源集。这就是TeamCity 快照依赖项的目的：它们将多个构建配置连接到称为执行链的单个执行链中，并且每个步骤都使用相同的源集 ，而与VCS更新无关。请注意，TeamCity使用术语“快照依赖关系”可能会使熟悉Maven快照依赖关系的人们感到困惑，这是两个不相关的概念。

快照依赖项的配置类似于工件依赖项。您可以在TeamCity文档中找到配置详细信息。

一起使用工件和快照依赖项

如果适用，建议定义构建配置之间的两种依赖关系，因为这不仅可以确保在整个链步骤中使用一致的源集，而且还可以确保生成的工件始终如一。现在，上面提到的工件依赖项中的“从同一链构建”的定义变得很清楚，因为这是此方案中唯一有意义的选项。

从某种意义上讲，您可以考虑在获取第一个源的“快照”之后，构建链步骤与VCS更新隔离地运行。链工件可以从相同来源重新创建，也可以通过与工件相关的链步骤传递。这使得链接步骤一致，可重现并且始终是最新的（当应用于使用链接工件时），而使用Maven快照依赖项则无法轻松实现。

TeamCity 7.0中的构建链可见性

TeamCity 7.0通过为构建链提供新的UI，使构建链的步骤可见并可以重新运行，从而将构建链的概念提升到了一个全新的水平。定义快照依赖关系后，新的“构建链”选项卡将出现在项目报告中，以可视化方式表示所有相关的构建链，并提供一种方法，使用原始提取的同一组资源手动重新运行任何链步骤。

建立链触发

将构建配置与快照相关性相关联，因此将其构建分组到构建链中，不仅使它们在使用的源方面更加一致，还影响将构建添加到构建队列的方式：触发某个链步骤后，默认行为是除了最初触发的步骤之外，还添加所有前面的链式步骤，并保持其各自的顺序。为了更加清楚，让我重复一遍： 触发某些链配置会在构建队列中添加之前的配置（在其左侧），而不是在其后的（在其右侧）配置 ，尽管乍一看似乎是违反直觉的。想法是标记链执行停止的位置，这恰好是最初触发的配置。它成为最后的执行步骤。

要在链配置中发现VCS更改时触发后续链步骤，您可以将带有“快照依赖项更改触发”选项的VCS触发器添加到配置中，这将是最后一个执行步骤。然后，只要更新任何前面的链式步骤，就会触发此配置，从而调度整个链式执行。

考虑到此行为，因此，您需要确定自动触发哪些配置以及应手动运行哪些配置。通常，VCS触发器可以自动触发对外部环境没有影响的较早的链式步骤，但是在人工验证了先前的链式结果之后，会手动调用最终链式步骤（可能会修改外部系统）。手动运行最终链式步骤的过程通常称为“促进”先前完成的构建。

样本构建链：编译，测试，部署

想象一下连接到构建链中的三个示例构建配置： "Compile" ， "Test"和"Deploy" ： "Deploy"是依赖于"Test"的快照，快照依赖于"Compile" 。

在此示例场景中，遵循上面给出的建议，将自动触发"Compile"和"Test"配置，而手动触发"Deploy" 。 "Compile"配置中的VCS更改仅触发该链式步骤的执行，而"Test"配置中的VCS更改则触发"Compile"和"Test"执行（按此顺序）。

将"Compile"配置添加到构建队列后，其源时间戳记将记录在服务器上，以用于所有后续链式步骤。如果将任何链式步骤连接到不同的VCS根，则其源也将根据相同的时间戳拉出。

促进完成的构建

一旦自动链执行停止（运行"Test" ），您可以通过单击未触发的"Deploy"配置上相应的“运行”按钮来继续执行（请参见上面的构建链屏幕截图）。或者，可以通过其“构建操作”促进完成的"Test"构建，并调用依赖于快照的配置-在这种情况下为"Deploy"配置。