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:
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.
Mediagrif Interactive Technologies