TFS Gated Build

Question

We have many solutions and each of these solutions have web projects and class library projects that the web projects in the solution refer to. Ultimately the assemblies from all the solutions go into a single website

Also note that the same project (Web or class library) may appear in multiple solutions and all the solutions also reference assemblies from a common location in TFS

At the moment we have individual builds for each of the solutions and they are set to be triggered manually As a result developers are able to check-in partial/incorrect check-ins and not realizing that they are injecting compile errors in one or more solutions

So we finally decided to have gated check-ins so that those changes that introduce compile errors are stopped from checking in

Question is how to we proceed? Each of the solution is quite big with over 30 projects

If we create gated check-in build for each solution, the build will take over 20 minutes to complete and that is too much of a time for developer to get a feedback that their changes are accepted or rejected

One solution may be to create gated check-in build for individual web projects, this will reduce the feedback time for developers but that will lead to too many builds to create and maintain Also when we have build per project and developers make changes to common files across projects (builds) one build may succeed while other may fail and thus allowing developers to check-in changes that will still break builds

Are there any guidelines to follow for scenarios like this?

Answer 1

I am not aware of any guidance in this area but...

Given your aim for a gated build is to validate your teams code has not broken anything then I assume the point is checking that the projects build and the unit tests pass. Everything else can be skipped.

So whilst I cant posit a direct answer to your question (i.e. 1 vs. many builds) I would say that your issue is delays waiting for a gated build to commit. I can offer a little wisdom from my experience trying to trim down TFS build times...

In order to shorten build times you can disable other optional parts of the process such as test impact analysis, source indexing, workspace cleaning, and labelling. finally ensure the source mappings are a small as possible.

That said you may find the biggest speed boost is ensuring the source mappings are very strict such that they only get source you absolutely need.

I would stick with the smaller number of builds with larger number of projects per build but that's just a personal preference, and its not based upon any science!

Finally if you share files between multiple projects or solutions, make a serious effort to refactor those shared bits into their own assemblies. Once you have done that then make NuGet packages for them, and use NuGet to reference them in yorr other projects. That way you not only avoid the need to build many projects/solutions when shared code changes, but you make the choice of what versions of common code your apps consume an explicit choice, not an implicit accident based on when you build.

Refactoring out shared files into shared NuGet packages can also increase build speed. It also makes shared dependencies al lot clearer.