Migrating from Continuum: Dependencies configuration and performance advices needed

Hello,

After years of using Continuum, I'm currently evaluating TeamCity as a replacement. But we have an issue with dependencies.

Many years ago, someone in development decided it was a good idea to have a jar file for every feature of our web archive projects.
1 jar for accounting java code, 1 jar for accounting web resource, 1 jar for email resource, 1 jar for email java code, and so on.

One of our project therefor has over 100 jars to build a set of 6 wars, most of the deeper jars being shared among all wars.
All those jars are linked  together with no cyclic dependencies chain.

With Continuum, it was easy. Put every jar and wars projects inside a group, hit Build Group and Continuum would resolve dependencies and build everything, from the deepest depencies jar to the applications War, sorting everything so that it can be build once.

I'm trying to reproduce a similar  behavior in Team City

So far, I have added all those projects with an identical configurations:

Triggers are :
VCS Trigger (every 60 seconds)
Maven Snapshot Dependencies Trigger (With Do not trigger a build if currently running builds can produce snapshot dependencies checked) with the default check timem which is 60 seconds.

I also configured the Snapshot Dependencies to point to our dependencies declared in the POM files.

But things don't go as I would like them to go.

Here is a simplified example:
Dependencies.png
In continuum, the "Group compile" would queues the builds in that order:
A.jar, G.jar, B.jar, C.jar D.jar, E.jar, B.war, F.jar, H.jar, A.war, C.war
In the case of D, it wouldn't start before B and C are both completed as they are queued in a single agent.

Now In Team City, I have the following behaviour:

With the External Snapshot Depedency trigger, if I modify A.jar:
1- A.jar would be queued.
2- Once A.jar is finished, B.jar and C.jar would be queued and build in parallel.
3- Once B.jar is finished, D.jar would compile, followed by F.jar and B.war then A.war
4- Once C.jar is finished, E.jar would compile along with D.jar because C has changed. The chain from B would repeat again.

So I would get,
A.jar,B.jar,C.jar,D.jar,F.jar, B.war,A.war,E.jarD.jar,F.jar, B.war,A.war,H.jar,C.war

I get a bunch of projects that are compiled more than once because the ones that depend on the start before all depedencies are build.
If I were to make F.jar depends on E..jar, then the F.jar and A.war would be compiled 3 time!

In the case the projects with overt 100 jars in it, the build queue reached over 250 entries!


When I configured the Snapshot Dependencies to use the chain building, I realize that the chain work backward.
Triggering a built of the War would build all it's childs rather than the childs triggering theirs parents.

And if I made a change in C.jar, chain building would require to trigger manualy the A,B and C wars, which would again result in multiple duplicated builds.


This leave me with External Snapshot dependencies Trigger being the best way to have the War compiled when I modify a jar.

However, the 1 minutes delay building a deep dependencies take a long time.
Does the trigger can be configured to skip the external check when a dependencies is built from within Team City?

Also, that 1 minute cause a lot of strain on our Nexus server! Every minute, Teamcity pulls EVERY snapshots checksum at once and I can see Nexus reach 800% CPU on a 24 logical core machine! And I'm only have 15 % of our projects imported in Team City

Can Team City does sequencial checks over the minute to distribute the load?
Does Team City cache the results obtained during a check run? In the example above, since C is a dependenies of D and E, is C checked twice per run (for D and E) or only once (the second check is cached)?


I really like Team City so far, but the people who are going to sign the check want to be sure it can handle our current load and setup.

Thanks
Philippe Busque
Mediagrif Interactive Technologies

1 comment
Comment actions Permalink

In this case there are two ways how it is better to setup build configuration:

1. Merge everything in one build step. It is recommended to use Incremental building: "Build only modules affected by changes" (setting of Maven build step), then the build will be split into two sequential Maven executions.
For example, if you change D.jar then for A,B,C jars the fisrt execution called preparation will be performed. This phase is intended for building the dependencies of affected modules will be build. While for D,F jars and A,B wars the second - main phase will be performed. It executes the main goal (for example, “test”), thus performing only those tests affected by the change. E,G,H jars and C.war won't be affected in this case. For more details you can read http://blog.jetbrains.com/teamcity/2012/03/incremental-building-with-maven-and-teamcity/.

2. The second solution is to use TC snapshot dependencies and VCS triggers (with no Maven Snapshot Dependencies Trigger). You can configure "VCS triggers" for A,B,C wars (last builds in the chain) and select "Trigger on changes in snapshot dependencies" option in this triggers. In this case if you change D.jar then A,B,C,F jars and A,B wars will be executed. Also when you configure snapshot dependencies, you can select an option "Do not run new build if there is a suitable one", then only changed builds will be triggered and other will be skipped.
For VCS  triggers you can also use setting "Default VCS trigger quiet period" (in Administration->General) - it determines the moment between the last VCS change is detected and a build is added into the queue.

> Also, that 1 minute cause a lot of strain on our Nexus server! Every minute, Teamcity pulls EVERY snapshots checksum at once and I can see Nexus reach 800% CPU on a 24 logical core machine! And I'm only have 15 % of our projects imported in Team City
> Can Team City does sequencial checks over the minute to distribute the load?
> Does Team City cache the results obtained during a check run? In the example above, since C is a dependenies of D and E, is C checked twice per run (for D and E) or only once (the second check is cached)?

No, we do not use cache, because it can lead to trigger delays. And if you have lots of jars in different build steps and use Maven snapshot dependencies triggers it can overload Nexus server. The two ways described above will help to avoid it.

0

Please sign in to leave a comment.