Controlling order of dependent build execution

I can't seem to avoid replicating dependency configuration throughout individual component builds.

For instance:

[A1]  [A2]  [A3]
  |     |     |
  +-----+-----+
        |     
   [Aggregator] [Install]
        |           |

        +-----+-----+
              |
         [System-Test]

When "System-Test" is started, I'd like "Install" to always run before any of the "A" series builds are executed.

I  can solve the problem by making "Install" a dependency of each of the  "A" builds, but that's not optimal to me since it's harder to manage due  to replication and not as clear to someone inspecting the "System-Test"  job dependencies.

I  could also solve the problem by using build steps instead of build  configurations  for "Aggregator" and "Install", but I would prefer to  have independently configurable jobs for those.  Perhaps a build-step  that simply triggered a different build configuration would work?   System-Test would then just have two additional, initial build steps:  "Start Install" and "Start Aggregator".

3 comments
Comment actions Permalink

Leon,

When you mention "dependency" what kind of dependency do you mean in real life and how is that configured in TeamCity?

From what you are saying it seems that recommended setup is to have snapshot dependencies configured:
from Aggegator to A1, A2 and A3
from all of A* to Install
from System-Test to Aggregator (and maybe also Install, though this will not change order of builds triggering)

If I understand correctly what you are suggesting, then this does not suit current TeamCity model well.
Build step is something running on the agent, so two agents will be busy (one runnign "Start Install" build step and other running actual "Install" build).

Moreover, in your approach at some point you might want more dependency-related feature that are already provided by snapshot dependencies and are probably bettern defined in declarative style of snapshot dependencies then in imperative style that you suggest.

Anyway, feel free to elaborate if snapshot dependencies do not suit the case well.

0
Comment actions Permalink

yaegor wrote:

When you mention "dependency" what kind of dependency do you mean in real life and how is that configured in TeamCity?


I meant "dependency" in the TeamCity "snapshot dependency" sense of the word.

I've recently been able to assemble a build sequence that combines triggers and snapshot-dependencies to get the solution I'm looking for.  I'm using the build completion triggers to control order and also making the triggered builds have snapshot dependencies on the triggering builds.  I think I just have to be careful to trigger the sequence from the first step in the chain through.  The snapshot dependencies are providing a mechanism for more easily troubleshooting failures through the TeamCity dependency tree.  I'm still not certain I'm using TeamCity in the most optimal way.

Maybe the attached diagram will help explain what I'm trying to do.

In summary:

  1. we are collecting components that have passed a component-test suite successfully
  2. placing them in a YUM -repo (they're RPMs)
  3. Installing them to various test system servers
  4. Smoke testing the installations
  5. Running system-level integration tests


Server System Integration Test TeamCIty Build Hierarchy.png

0
Comment actions Permalink

Leon,

Sorry for the delay in replying, I overlooked your post initially.

Thank you for the description of the configuraiton.

So far looks OK. If "depends on" is a snapshot dependency, I'd consider adding dependencies from all of System Integration Tests * to Smoke Test - Master and from System Integration Test - Master to System IntegrationTests * builds.
Then you can actually configure the nightly trigger in the System IntegrationTest - Master as triggering the build will put into the queu all the necessary builds down the chain.

0

Please sign in to leave a comment.