我们收集了 150 多个项目，重新配置并优化为多个 TeamCity 配置，具有多个构建代理，以尝试提高我们的构建服务器性能，目前以高度顺序的方式构建。
技术（Web、dotNet、VB6 和 COM+）和系统架构的混合意味着有各种步骤（配置）现在可以并行运行，但需要进一步组合在一起。
这是一个非常简化的依赖方案，但代表了我们遇到的问题。
A -> B -> Collate (-> Deploy)
A -> C -> Collate (-> Deploy)
问题是，如果对 A 进行更改，将导致 B 和 C 同时触发，这将导致整理（和部署）步骤运行两次，尽管这是 A 中的常见触发器。 正如我所说，这是对近二十种配置的实际集的简化，频繁的重建正在影响速度的提高。
谁能建议我确定 B 和 C 都将因 A 而触发的事实，并使整理步骤在触发整理步骤之前等待 B 和 C 完成？ 显然，对 B 或 C 的更改应该能够独立触发整理。
我是 TeamCity 的新手，但我相信这就是你需要的：
-
A：无触发器或依赖项 -
B和C：没有触发器，快照依赖于A -
Collate：VCS触发器，快照对B和C的依赖
通过该设置，VCS 单次推送将导致：
- 正好是
A、B、C和Collate的一个构建 -
A建于B和C之前 -
B和C在Collate之前建造
的 - 全部从 VCS 中的同一点构建
如果要将工件沿链向下传递，则还需要定义工件依赖项。
如果不同的版本使用不同的 VCS 存储库，则仍然不应在 A、B 和 C 上设置 VCS 触发器;而是在 VCS 触发器上设置 "快照依赖项更改时触发" 选项Collate 。