TFS Build Options Explained: Build Triggers

Team Foundation Server provides administrators with five different triggers when creating or editing a build definition. Each option is useful in the right scenario, so it's helpful to have a good understanding of each.

Manual
This is the only option which does not rely on any form of automation. Builds using a definition with the manual trigger must be explicitly requested by a developer.

Continuous Integration
When this trigger is selected, a new build will be queued every time a new changeset is checked-in. This is CI in its purest form (hence the name)!

Rolling Builds
While the CI trigger is simple and great, it has an Achilles' heel. Say, for example, that your build process takes 10 minutes to complete. And say that your development team is very busy and suddenly a dozen changesets are checked-in. You've suddenly got 12 builds in the queue and the last check-in won't be included in a build for two hours! That's no good. The Rolling Builds trigger solves this problem by grouping check-ins together. After one build using the definition completes, a new build will be queued with ALL of the changes checked-in since the previous one. Optionally, you can even set the trigger not to queue more often than every specified number of minutes. This way you can ensure that no changes will be stuck in limbo for too long between being checked in and being validated with a build.

Gated Check-in
While the Continuous Integration and Rolling Builds will help catch errors soon after code changes are checked-in, the Gated Check-in trigger will prevent a changeset from being committed (and therefore from ever impacting other developers) if it is not first validated by a successful build. When a developer performs a check-in, his/her changeset will be merged into a temporary shelf and a build will be queued. If the build is successful, the changes will then be committed to the target branch. Otherwise, they will be rejected and the developer must resolve the errors before attempting another check-in. The Gated Check-in trigger also provides an option to perform the validation build after a specified number of check-in attempts, rather than every time; this is similar in concept to the Rolling Build trigger.

Schedule
Scheduled builds will be queued and run at the specified times, regardless of when any individual check-ins occurred (although by default the build will be skipped if no check-ins have occurred since the last one). You may choose any number/combination of days, but can only select a single time of day to queue the build. If, for example, you wanted to schedule builds for 9:00 AM on Mondays and 2:00 PM on Thursdays, you would need to create two separate build definitions.