是否可以防止 TeamCity 中的构建链被中断？

我在 TeamCity 7.1.3 中进行了以下设置：

项目A

• 构建和部署 A
• 测试 A（快速）
• 测试 A（慢速）
• 测试 A（非常慢）

项目B

• 构建和部署 B
• 测试 B（快速）
• 测试 B（慢速）

A 的所有测试都依赖于“构建和部署 A”，B 的所有测试都依赖于“构建和部署 B”。依赖项都是具有以下设置的快照依赖项：

• 如果有合适的版本，请勿运行新版本
• 仅使用合适的成功构建
• 在同一代理上运行构建

所有测试都有 VCS 触发器。缓慢的测试仅在源代码管理中的特定文件夹发生更改时运行。当提交项目 A 时，以下项目将添加到构建队列中：

• 构建和部署 A
• 测试 A（快速）
• 测试 A（慢速）
• 测试 A（非常慢）

预提交构建在构建队列中以更高的优先级运行。因此，如果在“构建和部署 A”运行时对项目 B 进行预提交检查，则构建队列将如下所示：

• 构建和部署 B
• 测试 B（快速）
• 测试 B（慢速）
• 测试 A（快速）
• 测试 A（慢速）
• 测试 A（非常慢）

这种设置的问题在于，这意味着 A 的测试是在项目 B 部署之后运行的。这是一个问题，因为项目 B 的部署会覆盖项目 A 所需的一些文件。被个人构建覆盖的文件是已部署的文件，它们不在签出文件夹中，这就是它们不被回滚的原因。有什么方法可以强制测试的构建链不被中断？

如果我从依赖项中删除“如果有合适的构建，则不要运行新构建”设置，则每个测试都将需要完整的构建和部署。较慢的测试不能依赖于其他测试来形成线性链，因为有时会运行“测试 A（非常慢）”，但不会运行“测试 A（慢）”。

不幸的是，目前无法拆分构建和部署来创建工件。

有什么方法可以在 TeamCity 中有效地进行设置吗？

这是我收集的内容：

• A 和 B 应被视为互斥。
• A 的构建优先级应始终低于 B，但是
• 一旦开始，A就不应该被打断。

可能有办法在这方面与 TeamCity 对抗；我不知道。如果您愿意稍微改变一下流程，其中之一可能适合您：

1. 克隆您的环境，以便A and B可以部署到不同的目标。这将使它们能够完全独立地运行。使用多个构建代理（每个至少一个A and B) 允许更快、更高的优先级B与较慢、优先级较低的同时执行A。 （我认为，这将是一项重大福利。）
2. 让你的过程更加原子化。将各种构建/部署/测试部分合并到一个配置中，从而确保待处理的部分A构建链不能被取代B.