There will be occasions when building custom WebParts under a Continuous Integration strategy where you don’t necessarily want to just build on check-in, but also want to run continuous builds on a time laced schedule, regardless of whether it has been check-in or not. When attempting to just use triggers, you may find that this doesn’t work exactly.
Firstly, under most orthodox considerations a build is not considered to be under a CI umbrella if it is not triggered by a check-in. However, to get around this issue you can use Check-ins do not trigger a new build as a trigger then use the inbuilt Window scheduler to call TFSBuild.exe while passing in the correct arguments with the /msBuildArguments switch. Batch it up, and you will be ready to rock and roll!
When using SharePoint as part of build automation processes they generally rely on msbuild.exe to compile/test the solution. These projects can often times consist of a multitude of projects, from just one type to several hundred SharePoint projects. A problem that is frequent is if there are no build errors then all the SharePoint assemblies will be generated, and the world is great. However, for chained builds if one of the projects does not build even though there is no dependency between the projects it will skip compiling the others. Ideally, no compilation is skipped unless an explicit dependency has been noted, however using the most immediate solution, the ContinueonError and StopOnFirstFailure properties will not work.
As opposed to this approach, it is based to divvy your solutions based on relationships, thereby defining the relationships in a matter that provides true separation in TFS. While you will have more solutions, you can still be related sets of them and build your pass/fail gates to work in a more targeted manner. Following, any sort of orchestration could be used for independent compilation.