We are developing a project and we use VS 2013 and TFS 2013 Express for version control. In team project source control settings I created two check-in policy. First is changeset comment policy that works and builds check in policy that requires last build was successful. But I think builds check-in policy that does not work because any file that prevents successful build (for example there is a syntax error in this file and project cannot be built) can be checked in. I can check in all broken file(s) although builds check in policy is added. So I need your help, I don't want broken code in tfs.
1 Answers
1
votes
You need to set up a gated check-in build. Gated check-ins are a form of continuous integration that forces a build to run and validate that the code builds successfully (as well as enforcing that unit tests pass and code analysis is successful, depending on how you configure it). Only if the gated check-in is successful, is the code actually checked in.
However, checking in broken code is a cultural issue. Developers should be compiling and testing their code on their own without the need for an automated process to slap them on the wrist first. Gated check-ins will help you solve the cultural issue by making life inconvenient for people who routinely check in broken code.
On a large application, you'll actually want to have multiple gated check-in builds -- one for each logical subsection of the application. The gated check-ins need to run as fast as possible, because every second that someone else is waiting for a gated checkin to complete so they can get the latest code is wasted time. The longer they have to wait, the more likely it is that they'll go get coffee, use the bathroom, or otherwise take a break, which can be massively counterproductive if they were in a productive, focused headspace when they were more or less forced by the tooling to stop focusing.
