Gated check-ins are implemented on top of shelvesets. Once turned on for build definition, gated check-in will cause all check-ins to submit changes as shelvesets. The build server processes the shelveset and, if the build and tests are successful, the build server checks the changes into SCM and makes them available to other team members. Gated check-ins are subject to the same limitations as shelvesets though (http://blogs.msdn.com/b/buckh/archive/2006/01/10/511188.aspx ).As the project grows in terms of team and/or source code size, scalability of the TFS builds may become the next challenge. One of the easiest steps to address this problem is to add more TFS build agents. Since each build agent can work on one build at a time, having multiple build agents should allow TFS to process multiple check-ins concurrently, right?
For regular CI, adding build agents improves the overall development process. Each gated check-in requires "exclusive" write access to the source code during build and test, so all build agents, except one, will be idle.
Most developers face resource sharing issues everyday (database locks and scaling-out challenges are the most popular). Performance improvement efforts usually go either into scaling up or into eventually consistent world. Gated check-ins and TFS scalability are the same challenges but in a new context. The solutions are the same as well: scale up the TFS server or move into eventually consistent old-and-proven CI (check-in-build-test-report).
It is easy to test the behavior mentioned above by using VMs with Visual Studio/TFS (http://www.microsoft.com/download/en/details.aspx?id=240). Add another agent, download a large open source project (I used Orchard CMS), set up build with Gated Check-In, and try submitting two changes one after another. Only one agent will be working.
