Continuous Integration: Build Pipeline for dependencies .NET

Question

I am automating the build of my .net core solution using TeamCity v10:

lets say i have the following projects:

A -> B -> C ->D

A->D

The arrow indicates that Project B references project A and needs it be restored and built before.

Configuration

Project D is a web application that has to be published at the end (it also needs both C and A)

• For that to work I created a Team City project for each of A,B,C,D
• Then for each project I created a build definition that consists of two steps restore and build
• the restore and build steps specify the project.json file of the specified project (for example in project B case it would be "src\B\project.json"
• I added extra step for Project D, which is publish since it has to be published to IIS.

Snapshot Dependencies

Any build on projects that are referenced should trigger build on the dependent projects in order to make sure that changes would not cause other projects to break.

For this case, I created the following snapshot dependecies:

• B has snapshot dependency on A and Finished Build Trigger on that dependency
• C has snapshot dependency on B and Finished Build Trigger on that dependency
• D has snapshot depends on C and A and Finished Buid Triggers on those dependencies

If I trigger a build on A, its triggering another builds on the build Chain (Which is A->B ->C -> D).

Then, If I trigger C, its triggering only D.

However If I start from B, Or C without having done the trigger of A first, the build of B fails since it needs project A Output First.

Questions:

1. For the build Configuration steps, am i doing it in the right way, taking into consideration that I have other projects (F,G, H) that also refer to A and B.
2. If need to start building project B, how can configure it to build Project A first, if that was not built before.

Answer 1

The solution is to configure snapshot dependencies from B to A, from C to B, and from D to C. However, the dependency from D to A is excessive, because the whole build chain runs on the same revision.

If build B is triggered, then all build up the chain (A and B) should. There can be an option "Do not run new build if there is a suitable one" enable. In this case build B will reuse suitable build A, if it exists.

Regarding triggers:

• It's not recommended to use finish trigger in this case. To trigger the whole build chain, then we should run build D, so that it will add the whole chain in the queue.
• To trigger build chain automatically on changes in VCS root, configure only one VCS trigger in D build configuration with option "Trigger on changes in snapshot dependencies".

In this case if there are VCS changes in any build (A, B, C or D) the whole build chain will be triggered.