TFS multiple build definitions with shared resources between

Question

I'm trying to plan out build definitions for a TFS server and I'm running into an issues/question that I wanted to get clarification on prior to proceeding.

Here is a simplified version of our project setup, sorry for the crudeness I don't have a UML tool on this machine :)

What I'm trying to accomplish is the correct build definitions so that:

1. If Solution 1 has a check-in, build solution 1 and its dependent project Dependency project.
2. If Solution 2 has a check-in, build solution 2 and its dependent project Dependency project.
3. If Dependency Project has a check-in, build solution 1 and solution 2 (with Dependency project)
4. If a single check-in is done that touches all 3 projects (as an example) build Solution 1 and 2 only once

I will likely be using gated check-ins to prevent commit to source control in the event of a build break.

It's been a while, but I believe at the time if i had a 3 build definitions:

• Monitor Solution 1 Folder - build Solution 1
• Monitor Solution 2 Folder - build Solution 2
• Monitor Dependency Solution folder - build Solution 1 and Solution 2

This worked for the most part, however if a single check-in occurred on both Solution 1 and Dependency Solution, IIRC, Solution 1 would be built twice.

While this is an inconvenience and I don't have to figure it out, it would be nice to know how to do this the correct way.

Answer 1

@Kritner I would recommend that you create a NuGet package from the output of the dependency and that you publish that to an internal NuGet repository. Solution 1 and Solution 2 should then take a dependency on the NuGet Package.

That's one build detention that is triggered when the new source is checked in.

At this point you will get notification when you try to build either solution if there is a new version of the dependency for you to take. The developer building in visual studio will be able to choose wither this is the right time or not.

I would suggest that this is where you stop and allow the developers to choose when they upgrade. However you can go further.

If you use something like MyGet to host your dependency you can have it create a trigger for a build. You may be able to do this with VSO and Service Hooks, or you can write something that monitors for a new package and then triggers the other builds. If you only publish a package when you have a successful build and test you can increase quality of the dependency.