Is it just me or could the dependency build triggering in TC be smarter?

Assume TeamCity is configured with 10 projects named from 1 to 10 where each project is dependent on all the projects whose number is less than their own e.g.

project 10 is dependent on projects 1, 2, 3, 4, 5, 6, 7, 8, and 9
project 5 is dependent on projects 1, 2, 3, 4
project 2 is dependent on project 1
and project 1 has no dependencies.

If a change is committed for project 1 then building projects 1 to 10 sequentially would be the optimal way to ensure that all the dependency build triggers were satisfied while requiring the least amount of CPU.

From what I observed, the scheduling by TeamCity is definitely not optimal. For example, in the worst case, Team City could build the projects in the following order

1, 10, 9, 8, 7, 6, 5, 4, 3, 2, 10, 9, 8, 7, 6, 5, 4, 3, 10, 9, 8, 7, 6, 5, 4, 10, 9, 8, 7, 6, 5, 10, 9, 8, 7, 6, 10, 9, 8, 7, 10, 9, 8, 10, 9, 10

Is this an accurate assessment? In our current setup we have about 60 projects with lots of dependencies on one another and 7 build agents. Even with that many agents the build queue can sometimes get quite backed up. We will probably end up adding more agents but it would be nice if the builds were ordered in such a way to optimize their use.

I think this would make a great feature for the 4.0 roadmap ;^)

-Eric

3 comments

I've opened a feature request issue http://jetbrains.net/tracker/issue/TW-5272. Please everyone vote for it! ;^)

0

It sounds, that in your setup all 'components/projects' rely on the HEAD of all dependend 'components/projects'.
Otherwise your setup doesn't make sense to me.

We have a similar situation, but solved it without TC means.

Just create one build configuration within TC. This one has to check all your projects for changes (can be done with CVS ampersand modules for instance).
Then have a special build-target wich builds all projects in the correct order (1,2,3...,10) by itself.

I think TC dependency management is only suitable for 'higher level' task, like
1) build configuration 1 builds and deploys an application
2) build configuration 2 tests the deployed application in different browsers ...

For build and project dependency-management tools like maven, ivy or self written solutions with ant are better suited in my opinion.
This comes true if you start with release management.
That means your project 10 is dependend on version 2 of project 9, and version 3 of project 8 ....
Than you find a bug and bugfixed version 10 is dependend on version 2 of project 9 and bugfixed version 3 of projekt 8 ...

Since you then still want to be able to build such projects with TC you shouldn't be too dependend on TCs dependency build triggering.

Edited by: Stefan Hansel on Jun 16, 2008 4:48 PM

0

Yes, using the term component or module instead of project would better describe our situation.

You are correct that we have components that depend on the "HEAD" of other components. We use Ivy and many of our components are configured to depend on the "latest.integration" builds of other components.

But having a single build configuration for all the components is exactly what we are trying to avoid. Continuous integration builds should be fast. Our build system is modularized so that only what changes or depends on what changes needs to be built, not the entire application stack.

0

Please sign in to leave a comment.