Setting up Build environment in
TFS 2010
Managing source control in a relatively large team is
difficult, and consequence is, build errors might occur. So when other team
members take the latest version they might end up with build errors etc.
One can think of setting up a build system, if he is looking
for one or more of following requirements
-
People are not allowed to check-in if solution
is not compiling
-
If code analysis issues are not fixed
-
Emails can be triggered for people whose check-in
broke the build
-
Projects alert on check-in/build success/build
failure to the team
-
Scheduling build to be generated at fixed
intervals.
Assumption
-
Person configuring the build system must have
Admin previleges on the TFS Project.
Configuring the build
1.
Open visual studio as Administrator.
2.
Connect to Team explorer and select the project
for which you want to setup build system.
3.
Right Click on Builds -> New Build
Definition.
4.
New Build Definition Wizard appears as shown
below.
5.
Enter the Build Definition Name.
6.
Select Trigger option from left side pane.
Select the type of build option suitable for your project. For example if you
select Continuous integration each
check-in will be build whereas if we setup gated check-in only if changes are
building successfully.
7.
Now what projects to need to be build? Select
process tab from left pane and configure Projects
To Build
8.
Now where this build information will get stored?
For this we should setup a build drop folder on TFS server. Please contact your
TFS administrator to create a drop folder in TFS.
You can specify the drop folder location as
shown in snapshot below.
9.
Now the TFS is configured. But how team members
will know that a build has succeeded or not? For this configure email-ids of
team members in Project Alerts option.
Team Menu-> Project Alerts
So the build system is configured now. This
avoids the overhead of checking history whose check-in caused the build to fail
or if code analysis is done or not. Running test cases again and again with
each build. Setting up build definition also provides options to run all dlls
with *tests while generating a build. So if any test case fails build will be
failed and team members will be notified.
Sounds interesting?? So start using it right
away J
