Team Build 2008 API

I have installed Team Foundation Server 2008 Beta 2 on my staging environment this week. The installation process was smooth and except for some small issues I could start testing the release after a simple installation process.

Naturally, the first thing I have checked was the Team Build new features. I will not expand in the words regarding the new features because there are already some posts describing it (http://blogs.msdn.com/buckh/archive/2007/08/14/tfs-2008-a-basic-guide-to-team-build-2008.aspx). Anyway, some of the new features ease the management of the builds from the UI (Delete, Open Drop Folder…) and were available in Team Foundation Server 2005 using 3rdParty tools (TFSBuildManager). What I like the most is the Drop Management feature that completes the Continuous Integration feature. By using the retention policy of a build definition (Build Type is now Build Definition) you can define what and how to save builds. Builds can also be marked as save forever which can be useful when you want to mark a build that was released to a customer.

The second thing that I have checked was the new Team Build object model in this version. Since I'm a heavy consumer of the Team Build API I was curious to find out how it looks. For the record, TFSBuildManager works on Team Foundation Server 2008 (some of the interfaces became obsolete so I would probably have to work on a new version).

The first thing I have noticed is that the BuildStore interface became obsolete and it is replaced with the IBuildServer interface. So, in order to create an instance of the interface we need to do the following:

TeamFoundationServer tfs = new TeamFoundationServer("ServerName");

tfs.EnsureAuthenticated();

IBuildServer bs = (IBuildServer)tfs.GetService(typeof(IBuildServer));

In Team Foundation Server 2005 there was no interface to manage Build Type. If you wanted to query the server build types you needed to use the Version Control API to get the list of branches under the $/ProjectName/TeamBuildTypes branch. In 2008 the term Build Type is replaced with Build Definition. There is also a new interface to manage it named IBuildDefinition. Here's an example of how to get the list of build definitions for a project:

IBuildDefinition[] buildDefinitions = bs.QueryBuildDefinitions("ProjectName");

Another interface that became obsolete is the BuildData interface. Instead of using this interface we now have a new one named IBuildDetail. The following example shows the replacement for the method GetListOfBuilds that was available in 2005:

IBuildDetail[] buildDetails = bs.QueryBuilds("ProjectName");

The IBuildDetail interface is wider than the BuildData interface and it's in parallel to the big changes made to Team Build in 2008. Some of the new members we can use are:

• SourceGetVersion – A string that represents the version control source version for the build.
  
• KeepForever – A Boolean value that marks a build as one that won't be deleted while applying the retention policy.
  
• LabelName – A string value that represents the version control label of the build.
  
• CompilationStatus, TestStatus – A BuildPhaseStatus value that represent the phase status (Failed, Succeeded, Unknown).
  

One of the big changes in Team Build 2008 is the build agents. In 2005 build machines were related to a specific build type. In 2008, with the builds queue feature, you don't have to relate a build server to a specific build definition. Build servers are now treated as agents and can serve all build definitions. For each Build Definition you specify a default build agent. The build agent is represented through the IBuildAgent interface that was already available in 2005 but only for executing a build.

To get the list of build agents we need to do the following:

IBuildAgent[] buildAgents = bs. QueryBuildAgents("ProjectName");

To create a new build agent:

IBuildAgent buildAgent = bs. CreateBuildAgent("ProjectName");

buildAgent.MachineName = "BuildMachineName";

buildAgent.Name = "BuildAgentName";

buildAgent.BuildDirectory = @"C:\BuildDirectory";

buildAgent.Port = 9191;

buildAgent.Save();

There are some more properties to set for creating a new build agent but these are the required ones.

Starting a build is a little different too. Since we do not start a build but queue a build we need to use the QueueBuild method in the IBuildServer interface.

IBuildDefinition buildDefinition = bs. GetBuildDefinition("ProjectName", "BuildDefinitionName");

bs.QueueBuild(buildDefinition);

One thing I found missing in the current release API was the ability to edit build definition using the IProjectFile interface. The IProjectFile interface wraps the MSBuild project file but it is only available when creating a new build definition.

There is a lot more in the new Team Build API. I have tried to cover the basics in this post.

I hope I'll have some time soon to write the support for Team Build 2008 in TFSBuildManager. I already got some cool ideas using the new API.

Filename Collision - Another item with the same name exists on the server.

At one of our merges we encountered an error saying that there is a file collision and we could not complete the process. The error is raised when you are performing the check in after the merge. The merge itself passes with no error. It seem that it happens when 2 files/folders with the same name and location are added to both branches. While performing the merge the source branch treats the new item as a branch action to the destination branch which results in adding the file in the check in process. The merge process does not check if the file already exists and when you perform the check in you get the error and the only option to resolve it is to delete the local file (the file from the merge action). The problem is that we wanted the file from the merge source branch. To fix this we needed to delete the file in the destination branch (after performing undo pending changes for the merge) and than perform the merge again.

Terminals Achievements

We are celebrating 2 major events in Terminals life. The first one is that latest release was downloaded 10,000 times. The second one and the sweetest is that the project page is the first result in Google's search for the word Terminals (Out of 37,000,00 pages!!!). This is a result of the posts written regarding the utility and the people that are using it. Thank you all.

We are working on a new version with lots of features and we added some guys to help us with the development. Hope we can deliver it soon. Enjoy.