Comments on: Looking Ahead to 2010 http://elegantcode.com/2010/02/09/looking-ahead-to-2010/?utm_source=rss&utm_medium=rss&utm_campaign=looking-ahead-to-2010 Tue, 07 Feb 2012 23:42:00 +0000 hourly 1 http://wordpress.org/?v=3.0.5 By: John Sonmez http://elegantcode.com/2010/02/09/looking-ahead-to-2010/comment-page-1/#comment-53523 John Sonmez Thu, 11 Feb 2010 03:40:59 +0000 http://elegantcode.com/2010/02/09/looking-ahead-to-2010/#comment-53523 I'll have to try that out. I always wanted to enforce that, because to me it doesn't make any sense to check code into a broken build. If someone is checking code into a build that is already broken, how can they know if they broke the build more? I’ll have to try that out. I always wanted to enforce that, because to me it doesn’t make any sense to check code into a broken build. If someone is checking code into a build that is already broken, how can they know if they broke the build more?

]]> By: David Starr http://elegantcode.com/2010/02/09/looking-ahead-to-2010/comment-page-1/#comment-53518 David Starr Wed, 10 Feb 2010 19:59:35 +0000 http://elegantcode.com/2010/02/09/looking-ahead-to-2010/#comment-53518 Another option with 2010 TFS is the CI Check In Policy. This policy ensures that when a build is broken, no new check-ins by other people are permitted until the breaker fixes the build. You want to hold someone accountable? Tyr not letting the other team members check in until the build breaker gets it fixed. Wow. Will be interesting to see how that one plays out. Another option with 2010 TFS is the CI Check In Policy.

This policy ensures that when a build is broken, no new check-ins by other people are permitted until the breaker fixes the build. You want to hold someone accountable? Tyr not letting the other team members check in until the build breaker gets it fixed. Wow. Will be interesting to see how that one plays out.

]]> By: John Sonmez http://elegantcode.com/2010/02/09/looking-ahead-to-2010/comment-page-1/#comment-53499 John Sonmez Tue, 09 Feb 2010 21:57:49 +0000 http://elegantcode.com/2010/02/09/looking-ahead-to-2010/#comment-53499 I am a big fan of the Gated Check In. It is very difficult to get developers to pay attention to broken builds. By not allowing the build to be broken in the first place, you eliminate many of the problems and finger pointing. Sure someone can still break a functional automated test, but I think this kind of preemptive action will improve quality. Especially in the enforcement of static analysis tools. I am a big fan of the Gated Check In. It is very difficult to get developers to pay attention to broken builds. By not allowing the build to be broken in the first place, you eliminate many of the problems and finger pointing. Sure someone can still break a functional automated test, but I think this kind of preemptive action will improve quality. Especially in the enforcement of static analysis tools.

]]>