0

We set up TFS 2013 recently and tried to set up gated check-in. In our experiment, it correctly failed the build and rejected the bad check-in. However, both the build notification tray icon and the build tab on the TFS web access show the failure, and it is this way for all users. This will make everyone think "the" build is broken when it's just one person's "gate." It will skew metrics, too.

A) Why would this be the default behavior? It seems very counter-productive and counter-intuitive. [Or maybe this isn't the default behavior and our setup is hosed?]

B) Is there a configuration for the build tab where a rejected gated check-in/build is visible only to the person who broke it?

C) How can we make the build notifier tool ignore gated failures?

Vibrant Ice
  • 81
  • 6

2 Answers2

0

a) This is a public build. Why should it be failing. If the gated build is failing it shows a lack of care by the developers. Are they checking in any old thing? Are they running their unit tests first? It really sounds like you have a quality issue there.

That is why the gated-builds are still public builds.

b) no - Anyone can however send a Private build to the build server if they think that there may be an issue that they can't catch locally..

c) Each user can uncheck the monitoring of the gated build. I would however suggest that they should concentrate on not failing the build however rather than sweeping it under the carpet...

A filed build, even a gated one, should be the exception and not the rule...

MrHinsh - Martin Hinshelwood
  • 23,409
  • 5
  • 46
  • 69
  • To your point a) "It works on my box" is a common mantra. It isn't always due to the developer being careless. The build configuration may need to pull in another resource (which the solution already included, so the developer didn't realize anything else had to be done). We want to prevent this kind of issue, otherwise what's the point of a gated check-in? – Vibrant Ice May 15 '14 at 18:42
  • The purpose of gated builds is for really large teams to reduce occurrence of the main line being broken. If you have 350 developers and everyone brakes the build once a year then you can bet that the source does not work. Each breaker should be investigated and checks put in place so that it dies not happen again. Never have the same break twice! Otherwise you need more checks... – MrHinsh - Martin Hinshelwood May 15 '14 at 19:03
0

MrHinsh answered my question from a largely philosophical standpoint, and that led me to this article:

[http://adamstephensen.com/2012/11/01/gated-checkins-mask-dysfunction/]

I agree in principle with the article. However, because we are attacking agile processes in baby steps, we still want this extra safety check for the time being.

Below isn't the exact solution we wanted, but it is a hybrid of the approach in the article and my original question. It doesn't force gated check-ins, but it allows them to be done, giving risky check-ins a safety net. Code quality beyond build-ability will be addressed with other mechanisms outside the scope of this question.

The compromise solution is that "vanilla" changes would be checked in normally (after local testing, of course), and then the CI build would kick in. Fixing broken builds would be high priority to be addressed immediately.

But anything out of the ordinary (configuration changes, referencing new/different external dependencies, or just anything a developer is unsure of) would use a private gated check-in, but not on the main build, because we don't want everyone to be tricked into thinking the build is broken upon rejections. This build definition is a clone of the main build definition, but with the addition that upon successful check-in, it chains a build of the main build definition using this:

[How to chain TFS builds?

While the main build is redundant in most cases (race conditions may apply), it solves the immediate need.

Community
  • 1
  • 1
Vibrant Ice
  • 81
  • 6