构建依赖关系设置
此页面基于示例给出了 TeamCity 中依赖关系如何工作的一般概念。 关于依赖项的描述，请参阅 Dependent Build。
在许多情况下，将一个构建的输出用在另一个构建中，以及在同一源代码上顺序或并行运行多个构建都非常便利。 考虑一个典型的例子：您有一个需要在 Windows 和 macOS 下测试的跨平台项目，然后才能得到生产构建。 对于这种简单的情况，最佳的工作流程将是：
编译您的项目。
在同一源码上同时在 Windows 和 macOS 下运行测试。
在相同的源码上构建一个发布版本，当然，如果在两个操作系统下的测试都已通过。
您可以通过在 TeamCity 中配置您的构建配置之间的依赖关系来轻松实现这一点，就像这样：
在这里，compile、tests (win)、tests (mac) 以及 pack setup 是构建配置，自然而然地，depend on 指的是它们需要等待编译完成后才能开始测试。
通常被认为是一个 构建管道，在 TeamCity 中，一个相似的概念被称为 构建链。 在深入了解 TeamCity 的工作原理之前，我们先来解释一下此处给出的图表（包括引言中的图表）背后的图例：
| 一种构建配置。 |
| 快照依赖性在2个构建配置之间。 请注意，箭头显示的是触发构建配置的顺序，即 build chain 的流程，这意味着 B 在 A 之前执行。 然而，依赖项的配置是相反的方向（A 快照依赖于 B）。 箭头是这样绘制的，因为在 TeamCity UI 中，您可以找到构建链的视觉表示，它们总是根据构建链流程显示的。 |
| 构件依赖性。 箭头显示了构件的流动，依赖项则在反方向配置。 |
如您所见，TeamCity 中有两种类型的依赖关系： artifact 依赖和 snapshot 依赖。 用两个词来说，第一个允许在另一个中使用一个构建的输出，而第二个可以在特定的顺序中从几个构建配置触发构建，但是源是相同的。
这两种依赖性通常会一起配置，因为制品依赖并不影响触发构建的方式，而快照依赖本身并不重用制品，有时您可能只需要其中的一个。
依赖性是在构建配置设置的专用页面上配置的。
现在，让我们看看您可以如何运用 artifact 和 snapshot 依赖，以及它们的具体工作原理。
一个 工件依赖项 允许在另一个构建中重用一个构建（或其一部分）的输出。
如果构建配置 A 依赖于 B 的工件，则 B 的工件会在 A 的构建开始前下载到构建代理。 请注意，您可以灵活调整 artifact rules，以配置应取哪些构件及应将它们放置在何处。
如果由于某种原因，您需要将构件依赖信息与您的代码库一起存储，而不是在 TeamCity 中，您可以配置 Ivy Ant tasks 以在您的构建脚本中获取构件。
如果同时配置了快照和构件依赖性，且在构件依赖性设置中选择了 '来自相同链的构建 ' 选项，TeamCity 将确保从同一源构建下载构件。
快照依赖项是两个构建配置之间的依赖关系，允许从这两个构建配置中启动构建，并确保它们使用相同的源快照（对应同一时刻的源版本），并确保按照特定的顺序进行。
当您有一系列通过快照依赖关系相互连接的构建时，它们将形成一个 构建链。
最常见的创建 build chain 的应用场景是在不同的平台上运行您的项目的相同测试套件。 例如，您可能需要进行发布构建，并希望确保在不同的平台和环境中正确运行测试。 为了实现这个目标，您可以指示 TeamCity 首先运行一个集成构建，如果集成构建成功，再进行发布构建。
另一个情况是，当您的测试运行时间过长，因此您需要将它们提取到一个单独的构建配置中，但是您还需要确保它们使用相同的源快照。
一旦您定义了快照依赖项并触发了至少一次 构建链，构建链 选项卡将出现在 项目主页 和相关构建配置的 主页 上，提供所有构建链的视觉表现和以原始拉取的源代码集手动重新运行任何链步骤的方式。
为了理解快照依赖性是如何工作的，您可以将其想象为模块依赖性，因为这些概念是相似的。 然而，让我们从基础开始。 我们假设，我们有一个 build chain：
如果触发了 A1 的构建，整个构建链 A1...AN 将被添加到 构建队列中，但是并非反之！ - 如果触发了 AN 的构建，它不会影响构建链中的其他任何内容，只有 AN 会运行。
构建按照从 AN 到 A1 的顺序依次运行。 构建 A(k-1) 不会开始，除非构建 Ak 成功完成。
链中的所有构建将使用相同的源快照，也就是说，会明确指定源代码的修订版本，该修订版本是在构建链被添加到队列时计算的。
现在让我们详细介绍并提供一些例子。
假设我们有以下的 构建链，没有额外的选项 - 纯快照依赖。
TeamCity 解析整个构建链并对所有构建进行排队 - A ，B 和 C 。 TeamCity 知道构建需要按照严格的顺序进行，所以它不会在构建 B 成功完成之前运行构建 A，也不会在构建 C 成功完成之前运行构建 B。
当构建被添加到队列时，TeamCity 就会开始检查整个构建链中的变化并同步它们 - 所有构建都必须从同一源快照开始。
请注意，如果与快照依赖关联的构建配置 共享相同的 VCS 根集，所有构建将在同一源上运行。 否则，如果 VCS 根是不同的，VCS 中的更改将对应于相同的时间点。一旦构建 C 完成，构建 B 就开始，依此类推。 如果构建 C 失败，TeamCity 默认不会继续执行链中的其他构建，但这种行为是 可以配置的。
同样的过程也将适用于构建链 B->C。 构建 A 不会受影响，也不会运行。
当触发最终构建 A 时，TeamCity 解析构建链并将所有构建 - A 、B1 和 B2 都放入队列中。 A 构建将不会开始，直到 B1 和 B2 都准备就绪。
在这种情况下，无论是 B1 或 B2 先开始都无所谓。 就像第一个例子中一样，当所有构建都被添加到队列中时，TeamCity会检查整个构建链中的更改，并将它们进行同步。
所有属于构建链的构建都被放置在队列中。 但是，TeamCity 可以检查是否已经有适当的构建，即使用了所需源快照的已完成构建，而不是强制从构建链运行所有构建。 匹配的排队构建将不会运行并且会从队列中删除，而 TeamCity 将会把依赖性链接到适当的构建。 要启用此功能，请在配置快照依赖项选项时选择 '如果有合适的构建，不执行新的构建'。
另一个可以让您控制如何重用构建的选项被称为 "只从合适的构建中使用成功的构建 "，当有合适的构建，但并未成功时，它可能会有所帮助。 通常，当链中出现构建失败时，TeamCity 不会继续执行链中的其余部分。 然而，启用此选项后，TeamCity会在这些源上再运行一次这个失败的构建。 这有何用处？ 例如，当构建失败是由于连接到 VCS 时出现问题时。
如果您在创建快照依赖性时禁用“执行版本同步 ”选项，那么在将构建从一个部分提升到另一部分时，TeamCity 将能够为链的各个部分使用不同的修订版本（在 构建链中阅读更多信息）。
让我们来探讨一下 deployment chain 的例子：
与以下构建配置一起：
D: 编译
C: 集成测试
B: 系统测试
A：部署
在这里，构建 B 的快照依赖项中 "强制执行修订同步" 选项被禁用，而 C 和 A 的快照依赖项中此选项得到启用（默认状态）。 根据这些设置，TeamCity 将在 D 和 C 之间，以及 B 和 A 之间同步修订版，但是可以对链条部分 D-C 和 B-A 使用不同的修订版。
在我们的例子中，D 和 C 的修订版本为 1，B 的修订版本为 2，而 A 的修订版本为 3。
如果您想要运行旧版编译构建 D，并使用最新的部署配置 A，同时跳过集成测试 C，您可以直接将构建 D 提升至 B。 TeamCity 将使用修订版 1 运行 D；然后，它将以 A 的较新修订版同步 B，并使用修订版 3 运行 B 和 A。
通过启用和禁用不同构建配置链的依赖项的此选项，您可以对您的设置进行更多控制并使其更灵活。
为了防止修订版本之间的冲突，避免配置这样的链，其中依赖构建（A）必须与其几个直接依赖构建（B）和（C）同步修订版本，而这些构建在他们对其他某些构建（D）的快照依赖项中的 "Enforce Revisions Synchronization" 选项有不同的状态。
请改为使用以下有效的链：
1. 同步已经被启用于 D-B-A 构建流程，但在 D-C-A 中被禁用。
2. 已为 D-B 和 D-C 启用同步，但 B-A 和 C-A 的同步被禁用。
这个选项设计用于此类情况：构建链中的一个构建修改了系统环境，并且下一个构建依赖于该系统状态，因此必须在同一构建代理上运行。
如果其依赖项失败，您可以配置最终构建行为的可能性。
VCS 构建触发器还有另一个 选项，可以改变构建链的触发行为。 启用此选项后，即使在依赖项中检测到更改，而不是在最终构建中，整个构建链也将被触发。
让我们从示例中取出一个构建链： pack 设置—— 依赖于 —— 测试—— 依赖于 —— 编译。
在 pack 设置 配置中设置了 VCS 触发器后，当 TeamCity 检测到在 pack 设置 中的变更时，整个构建链通常会被触发；在 编译 中的变更只会触发 编译 ，而不会触发整个链条。 如果您希望在 编译 中的 VCS 更改触发整个链，将带有 "在快照依赖中的更改上触发" 选项 的 VCS 触发器添加到链的最终构建配置 pack 设置。 这不会改变构建执行的顺序，但只有在任何快照依赖项发生变化时，才会触发整个构建链。 在此设置中， 编译 或 测试 构建配置不需要 VCS 触发器。
依赖项的更改
对于具有快照依赖关系的构建配置，您可以启用显示来自这些依赖关系的递归变化。 该设置被称为 "显示来自快照依赖性的更改 "，可在"版本控制设置"步骤的构建配置管理页面的高级选项中找到。
启用此设置会影响构建配置的待处理更改，构建历史记录中的构建更改，更改日志和问题日志。 来自依赖项的更改标记为 
。 例如：
启用此设置后，带有 "仅在有待处理更改时触发构建" 选项的 Schedule Trigger 也会考虑来自依赖项的更改。
TeamCity 提供了使用当前构建所依赖的构建（通过快照或者工件依赖）所提供的属性的能力。 当构建 A 依赖于构建 B 时，您可以将构建 B 的属性传递给构建 A ，即属性只能按照构建链流向传递，而不能反向传递。
有关如何使用链中前一个构建的参数的详细信息，请参考 依赖性属性 部分。
一个构建链可以有无限数量的并行和顺序连接。 如果满足以下条件，构建将会并行运行：
这些构建中的每一个都对同一依赖构建具有自己的快照依赖性。 这些构建将能够在依赖构建完成后立即开始。
服务器上有足够的免费构建代理。 如果代理繁忙，TeamCity 将会按照代理负载的顺序，依次执行这些构建。
构建链和清理
默认情况下，TeamCity 会保留清理过程中链的一部分的构建，但您可以关闭此选项。 参阅 清理 描述以获取更多详情。
Artifact 依赖及清理
如果其他构建下载了工件，并且这些构建尚未清理，那么可能无法清理这些构件。 对于具有配置的工件依赖关系的构建配置，您可以指定此配置从其他构建下载的工件是否可以被清理。 这个设置可以在 清理策略 页面上找到。
在链中运行个人构建
如果您运行的个人构建是 构建链 的一部分，那么所有依赖于它的构建也将作为个人构建运行。
然而，如果您在依赖设置中启用了 合适构建的复用，TeamCity 将尽可能优化该链。 如果运行个人依赖构建没有带来任何价值，或者与检出规则相冲突，那么 TeamCity 将使用已完成的非个人构建替代。
感谢您的反馈！