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.
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.