Exploiting concurrency with multiple build agents

I just switched over to TeamCity 5 from ccnet, and am slowly getting a feel for the TeamCity way of doing things.

I have two build agents on my build server, which I set up in the hopes of reducing build times by taking advantage of concurrency.  Unfortunately it's not working out as I'd hoped.

Say I have three projects, Lib, Installer, and Tests.  Lib is the app, Installer is obviously the installer, and Tests is the the unit tests.  Further say that each takes one hour to build.

With one agent, the build order looks like this:


Lib => Installer => Tests

With two agents, I was hoping the build order would look like this:

     |=> Installer
Lib =|
     |=> Tests


Unfortunately, this isn't what's happening.  Instead, Lib starts building on Agent1, and during the one hour build we commit another change to Lib.  This triggers Lib building the next build on Agent2.  Because they're both running at more or less the same time, Agent1 spends three hours doing a build, and Agent2 spends that same three hours doing another build one or two revisions newer.  This isn't what I want.  I'd rather Agent2 wait for Lib to finish so it can pick up either Installer or Tests, and leave the other build configuration to Agent1.

Is there any way in TeamCity 5 for me to do this?  Note the example above is a simplification; my actual configuration is much more complex.

Thanks,

Adam

1 comment
Comment actions Permalink

Adam,

Do you use dependency triggers for running Installers/ Tests after Lib?

If Installers or Tests checkout sources, you will proabbly need to use snapshot dependencies instead (and trigger Installers and Tests using VCS trigger with  "Trigger on changes in snapshot dependencies"set to ON).

You can probably try to set "Limit the number of simultaneously running builds" to 1 on the general settings for Lib. If snapshot dependencies are used, this will probably help in simple cases.

There is also a plugin that handles managing concurrent running of builds based on read/write locks logic (see comments to http://youtrack.jetbrains.net/issue/TW-3798), but this is probably for more advanced cases.

Alos, adding one more agent seems to alleviate the issue.

0

Please sign in to leave a comment.