Performance 在TeamCity中的多个并行构建后触发一次后续构建_Performance_Build_Continuous Integration_Teamcity

Performance 在TeamCity中的多个并行构建后触发一次后续构建

performance build continuous-integration teamcity

Performance 在TeamCity中的多个并行构建后触发一次后续构建,performance,build,continuous-integration,teamcity,Performance,Build,Continuous Integration,Teamcity,我们有150多个项目，我收集了这些项目，通过多个构建代理，将其重新配置并优化为多个TeamCity配置，以尝试提高构建服务器的性能，目前构建是以高度有序的方式进行的技术（Web、dotNet、VB6和COM+）和系统架构的混合意味着现在可以并行运行各种步骤（配置），但需要进一步整合这是一个非常简化的依赖场景，但代表了我们的一个问题 A -> B -> Collate (-> Deploy) A -> C -> Collate (-> Deploy) 问题

我们有150多个项目，我收集了这些项目，通过多个构建代理，将其重新配置并优化为多个TeamCity配置，以尝试提高构建服务器的性能，目前构建是以高度有序的方式进行的

技术（Web、dotNet、VB6和COM+）和系统架构的混合意味着现在可以并行运行各种步骤（配置），但需要进一步整合

这是一个非常简化的依赖场景，但代表了我们的一个问题

A -> B -> Collate (-> Deploy)
A -> C -> Collate (-> Deploy)

问题是，如果对a进行更改，将导致B和C两个触发，这将导致整理（和部署）步骤运行两次，尽管这是a中的常见触发。正如我所说，这是对几乎20个配置的真实集合的简化，频繁的重建正在影响速度的提高

有没有人能提出任何方法，让我确定B和C都会因a而触发，并让整理步骤等待B和C都完成，然后再触发整理步骤？显然，更改为B或C应该能够独立触发Collate。

我是TeamCity的新手，但我相信这正是您需要的：

```
A
```
：无触发器或依赖项
```
B
```
和
```
C
```
：无触发器，快照依赖于
```
A
```
```
Collate
```
：VCS触发，快照依赖于
```
B
```
和
```
C
```

通过该设置，VCS单次推送将导致：

只有一个版本的
```
A
```
、
```
B
```
、
```
C
```
和
```
Collate
```
```
A
```
在
```
B
```
和
```
C
```
```
B
```
和
```
C
```
之前构建的
```
Collate
```
都是从VCS中的同一点构建的

如果您想将工件传递到链上，那么您还需要定义工件依赖关系

如果不同的版本使用不同的VCS存储库，那么您仍然不应该在

、

和

上设置VCS触发器；相反，您在VCS触发器上为

Collate

设置了“快照依赖项更改时触发”选项，但不知道您当前使用的触发器是什么-A、B和C上的触发器是什么？TFS中针对A、B和C的VCS触发器以及之前步骤的完成生成，因此B将在完成生成时触发（C也是如此）然后Collate将在B或C完成构建时触发。您当前有哪些触发器（快照和人工制品）？@psych抱歉，我不明白您要求的是什么，我在原始的“简化依赖场景”和我之前的评论中没有提供。从A到B和C再到整理的工件，VCS会触发。对不起，我的评论毫无意义。我的意思是说您设置的依赖项不是触发器，所以您似乎是说让依赖项强制构建前面的步骤，而不是触发器？有意思，我得试一下，我会告诉你我的进展。谢谢。是的，没错。TeamCity希望您告诉它您想要的最终结果——它负责确定哪些其他构建需要触发才能获得该结果。那很好用！由于真实场景的复杂性，我还有几个怪癖需要解决，而不是上面的简化场景，但它似乎可以更好地优化构建。干杯，伙计。