6
votes

We have over 150 projects which I have gathered together, reconfigured and optimised into multiple TeamCity configurations, with multiple build agents, to try to improve our build server performance which currently builds in a highly sequential manner.

The mix of technologies (Web, dotNet, VB6 and COM+) and system architecture means that there are various steps (configurations) which can now run in parallel but which need to come together further down the track.

This is a very simplified dependency scenario but representative of a problem we have....

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

The issue is that, if a change is made to A, it will result in B and C both triggering which will result in the Collate (and Deploy) steps running twice, despite being a common trigger in A. As I say, this is a simplification of the real set of almost twenty configurations and the frequent rebuilds are impacting the speed improvements.

Can anyone suggest any way that I can identify the fact that both B and C will be triggered as a result of A and make the Collate step wait for both B and C to complete before triggering the Collate step? Obviously a change to B or C should be able to trigger the Collate independently.

1
Hard to say without knowing what triggers you are currently using - what are the triggers on A, B and C?infojolt
VCS triggers from TFS for A, B and C and Finish Build for prior steps, so B will trigger on A Finish Build (as will C) then Collate will trigger on B or C Finish Build.Mike
What triggers (snapshot and artefact) do you currently have?infojolt
@psych Sorry, I don't understand what you're asking for that I haven't already provided in the original "simplified dependency scenario" and my previous comment. Artifacts from A to B and C and then on to Collate, VCS triggers.Mike
Sorry my comment made no sense. I meant to say what dependencies you have set up not triggers.infojolt

1 Answers

14
votes

I'm new to TeamCity, but I believe that this is what you need:

  • A: no triggers or dependencies
  • B and C: no triggers, snapshot dependecies on A
  • Collate: VCS trigger, snapshot dependency on B and C

With that setup, a VCS single push will result in:

  • exactly one build of A, B, C and Collate
  • A built before B and C
  • B and C built before Collate
  • all built from the same point in VCS

If you want to pass artifacts down the chain then you will need to define artifact dependencies as well.

If the different builds use different VCS repositories, then you still should not set VCS triggers on A, B and C; instead you set the “Trigger on changes in snapshot dependencies” option on the VCS trigger for Collate.