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.
3 comments:
Nice post. I look forward to seeing what you come up with.
Buck
This content has been Agglom (erated) with other similar ones on http://www.agglom.com/agglom/57 - Team Foundation Server (TFS) 2008 API (Orcas)
Now that Microsoft.TeamFoundation.Build.Proxy has been deprecated what else can use to get a list of changesets for a specific build.
IBuildserver does not expose useful methods for this.
My end goal is to retrieve a list of changed assembies and their dependencies for a specific build.
Any ideas?
Emil
Post a Comment