Overview of Team Build in Visual Studio Team System 2008

Posted by: Subodh Sohoni , on 4/10/2008, in Category VSTS & TFS (Azure DevOps)
Views: 22551
Abstract: Visual Studio Team System 2008 is a minor version with only some incremental changes happening over Visual Studio Team System 2005. One of the areas where some major changes can be seen is Team Build. In this article we will take a fresh look at Team Build as in VSTS 2008.
Overview of Team Build in Visual Studio Team System 2008
Visual Studio Team System 2008 is a minor version with only some incremental changes happening over Visual Studio Team System 2005. One of the areas where some major changes can be seen is Team Build. In this article we will take a fresh look at Team Build as in VSTS 2008.
First thing we realize when we install TFS 2008 is that build capability is not installed on the TFS by default. We need to take decision to install it on TFS or any other machine and explicitly install it on that machine although the installables are still available with the installables of TFS 2008.
In VSTS 2008, Team Build still remains a wrapper around Microsoft’s workhorse for build execution that is MSBuild. Concepts of Targets, Tasks, ItemGroups and PropertyGroups have not changed. (For more details on these please read the article An Overview of Team Build in VSTS ). TFSBuild.proj file has not changed much. The first difference is that some of the properties which were required to be stored in this file are now stored in the database. For backward compatibility they do appear in the file created by the build definition creation wizard but with the values UNKNOWN. These properties are BuildMahine, BuildDirectoryPath and DropLocation. They are collected by the wizard and stored in the database. We can create Build Definition, which is somewhat similar to Build Type which existed in VSTS 2005. Each build definition will have a TFSBuild.proj file created to store the build data. Configuration of each build is stored as Build Agent and such Build Agents are reusable for multiple build definitions. We can store TFSBuild.Proj file now along with the solution which is to be built instead of keeping it compulsorily in the TeamBuildTypes folder.
When the wizard for build definition is started from context menu item “New Build Definition” of the Build node in the Team Explorer, it accepts certain inputs from the user. These inputs are Build Definition Name, Description, Workspace to be used and Path of the TFSBuild.proj file. Along with this we also have to provide the Build Type (Release of Debug), Target Platform, Test List of the tests to be executed and the policy for code analysis to be done as part of the build. A new facility regarding tests is the ability to also provide names of the assembly which contain the compiled test projects.
A new feature of the wizard is to specify retention policy for the builds which are executed. This policy is based upon the type of output viz. Failed, Stopped, Partially Succeeded and Succeeded. For each of these outcomes we can specify count of builds to be retained. We can specify values like “Keep All”, “Keep None”, “Keep Latest Only” or a count of builds to save space.
Build Definition
As the next step of the wizard, we have to specify the Build Defaults such as the name of the Build Server and the share name as the drop location.
Team Build 2008 has the capability to schedule and trigger the build. This feature takes care of a common requirement which is “Continuous Integration”. In VSTS 2005 this feature was not present out of box and we needed to play with Eventing Service and Team Foundation Object Model to provide it as a customization of standard installation.
Build Definition Trigger
Now we have the option to set classical Continuous Integration by selecting “Build Each Check-in” and we also have the options to accumulate check-ins till earlier build is executing with a variation to also wait for certain amount of time before the build is triggered even if some build requests are queued. It is also possible to schedule the build to execute at certain periodicity, on specified days, at specified time every week.
Team Build 2008 is more efficient in a way by not building the source if it is not changed after it is built once. When continuous integration is configured for a build, it intelligently triggers the build only if the check-in is for the solution which is configured for that build. It means that if the check-in is for a branch and continuous build is configured for a different branch in the source control, then the build will not be triggered.
To execute the build we put it in the queue of the build requests. While putting it in a queue, we can specify the priority of the build and the build engine will start execution of the build request with highest priority after the execution of the current build is over. If there are multiple build requests queued with the same priority, then the normal queue behavior will be followed.
When we list the executed builds for a build definition, we can filter the list based upon Build Quality and the date. From the same UI we can also edit the Build Agent properties.
Build in TFS 2008 is not compatible with the one in 2005. Team Explorer of VSTS 2008 cannot manage builds created in VSTS 2005. If we need to execute builds created with VSTS 2008 from Team Explorer 2005 then TFSBuild.proj file needs to be at default location, i.e. in the TeamBuildTypes folder in source control.
Team Build is an area where we can see a lot of improvement in VSTS 2008 as compared to VSTS 2005. Major new feature is Continuous Integration and scheduling of the builds. Manageability of the build has also improved with the ability to store TFSBuild.proj at a convenient location. Efficiency of the build has also improved as unnecessary build of the unchanged source is avoided.
I hope this article was useful and I thank you for viewing it.
If you liked the article,  Subscribe to my RSS Feed.

This article has been editorially reviewed by Suprotim Agarwal.

Absolutely Awesome Book on C# and .NET

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce the The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this eBook aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on .NET Standard and the upcoming C# 8.0 too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!

What Others Are Reading!
Was this article worth reading? Share it with fellow developers too. Thanks!
Share on LinkedIn
Share on Google+

Subodh is a consultant and corporate trainer. He has overall 28+ years of experience. His specialization is Application Lifecycle Management and Team Foundation Server. He is Microsoft MVP – VS ALM, MCSD – ALM and MCT. He has conducted more than 300 corporate trainings and consulting assignments. He is also a Professional SCRUM Master. He guides teams to become Agile and implement SCRUM. Subodh is authorized by Microsoft to do ALM Assessments on behalf of Microsoft. Follow him on twitter @subodhsohoni

Page copy protected against web site content infringement 	by Copyscape

Feedback - Leave us some adulation, criticism and everything in between!





C# Book for Building Concepts and Interviews



jQuery CookBook