Are my changes in the release?

One question often asked from a release manager is "Are my changes in the release". This happens often especially when it comes to the crunch i.e. near the release deadline or at times of sending a patch to fix of a urgent high priority issue.

Team Foundation Server behaves slightly differently in selecting changesets to include in the build based on the build trigger. So, if you are pondering that a changeset you were not expecting in the build is not part of it, it might be useful to look at the build trigger option.

There are 5 options to trigger a team build and here is how changesets are chosen in each build case:

Manual:

As named, the build with a manual trigger option will only occur a user queues a build manually. For builds triggered manually the executing build will fetch all the changes in the Active working folders until the point of time when the build fetches source files.

For example, let's say that the build was queued at 8:45 am but remained in the queue for 10 minutes So it started running at 8:55 am. Meanwhile, a couple of changes (changesets 11495 and 11497) were checked in at 8:47 am and 8:51 am respectively. The build would include both the changesets.

Continuous Integration :

If this trigger is selected, a build is queued every time a changeset is checked in. In this case, the build request also contains the changeset number that queued the build. For all CI builds, all changes in the Active working folder up to the changeset that queued the build would be in included in the build.

For example, if the build was queued at 8:45 am by a changeset 11495 and remained in the queue for 10 minutes i.e. it started running at 8:55 am. Meanwhile, another changeset 11497 was checked-in at 8:47 am. Another build was triggered. The first build would not include the changes present in the changeset 11497 even though the changes were already in source control at the time when the build was fetching source files.

Rolling Build:

With this trigger option, Team Foundation Server still triggers a build on a check-in but only if there are no build already in the queue or in progress. If a build is already in queue or in progress, it accumulates all changes and queues a new build once the first build is completed.6

Similar to Continuous Integration, the build request contains the changeset that queued the build and all changes up to that build number are included in the build.

For example, if the build was queued at 8:45 am by a changeset 11495 and remained in the queue for 10 minutes i.e. it started building at 8:55 am. Meanwhile, two changesets 11497 and 11498 were checked in checked-in at 8:47 am and 8:51 am respectively. Another build would be triggered after the first one is completed. The first build would not include changes in the changesets 11497 and 11498 even though the changes were in source control at the time when the build fetch source files.

Gated Check-in

With Gated check-in, a build is triggered for each changeset and only committed or check-in once the build is successful. With this option a build is queued for each changeset (assuming the option to merge and build gated builds is not selected).

Like Continuous integration, every build request has a changeset that triggered the build. However, unlike CI the build will include all changes which are check-in until the build fetches the source control and not when the build was queued.

For example, if the build was queued at 8:45 am by a changeset 11495 and remained in the queue for 10 minutes i.e. it started running at 8:55 am. Meanwhile, another changeset 11497 was checked-in at 8:47 am. Another build was triggered. The first build did not include changes in the changeset 11497 since they are checked-in yet. However, the second build did include changes checked-in as a result of the successful completion of previous build even though at the time of queuing the build these changes were not checked-in.

Schedule:

The scheduled build is triggered repeatedly on a particular day / time. For scheduled builds, TFS picks up all the changesets until the time when the build was queued.

For example, let's say that the build was queued at 8:45 am but remained in the queue for 10 minutes and start started running at 8:55 am. A couple of changesets 11495 and 11497 were checked in at 8:47 am and 8:51 am respectively. The build would NOT include both the changesets.

PS: To read more about the build triggers and the scenarios and the optimal scenarios to use them, read the Build Customization Guide produced by Microsoft ALM rangers.