Planet SCM

At the Microsoft Worldwide Partner Conference in Houston today, Corey Steffen (General Manager of Teamprise and the guy that pays my wages) announced the public availability of Teamprise 3.1.

This is a maintenance release free to everyone with a valid Teamprise 3.0 license and includes several bug fixes along with a few new features.  For the proper release notes, take a look here.  However I just wanted to point out a few highlights.

Improved Offline Support

With-out doubt, the biggest new feature in Teamprise 3.1 for most people will be the improved offline support. If you right click on a project in the Eclipse IDE, you are now presented with a "Go Offline" option which allows you to tell Teamprise not to bother trying to talk to TFS for a while (previously you had to restart Eclipse for Teamprise to ask you if you wanted to go offline, and only then after it had tried *really* hard to connect).

While offline, you can still perform all the file operations like you expect -- you can add, edit, move and delete files just like if you were online.

When you want to come back online (say when you have stepped back out of the plane, bus, meeting room), you can right click on the project and say "Return Online" and Teamprise will do it's best to detect what changes have happened while you were away, giving you the option to pend those changes.

There is even "return online" capability in the stand-alone client Teamprise Explorer which is very neat and makes working with tools that are not TFS aware a little easier too.  The actual algorithm used by the return online feature is more sophisticated than just checking for read/write status in your local workspace, we also do some magic and compare checksums of the file contents etc.  Fellow Teamprise blogger Ed Thomson was the lead developer for the offline work and he has some more details on his blog.

TFS 2008 SP1 New Feature Support

Service Pack 1 of Team Foundation Server 2008 is hopefully due out soon, and with it come lots of lovely new features. We took advantage in the timing of our 3.1 release to update Teamprise to support some of the new server capabilities so that they are available to our customers as soon as TFS 2008 SP1 arrives.  These include:

• Last check-in date/time column (see my previous post about this feature)
• Support for work item meta-data filtering option (note that this option is already being used on some of the CodePlex servers so if you use Teamprise to talk to the work item functionality in CodePlex then you probably want to upgrade to Teamprise 3.1, after all the price is right :-) ).
• tf branch -checkin command, the fastest way to create large branches and perform the check-in at the same time.

Command Line Client Improvements

In this release we are making publicly available a bunch of improvement and new features that we added to our command line client after some great feedback from one particular customer who has un-questionably the largest and most demanding Team Foundation Server install base on the planet. In particular we have added the "-format:xml" option for most commands in addition to the usual -format:brief and -format:detailed.  The -format:xml option will output data from the command line client in a format easily XML parseable without truncating output which makes it much easier to use and parse command line output in scripting scenarios.  However, there have been many more improvements so check out the release notes for more information.

64-bit support on Windows.

Not really worth calling out separately only to say that Teamprise is now the world's first commercially available x64 TFS client for Windows :-)

While we are a Java application, as mentioned before, we have a bit of JNI code to do the stuff not possible from all the JRE versions that we support (such as native authentication on Windows or making a file writable).  Also we use SWT to give us a native look and feel on all platforms and SWT works by using lots of JNI to do the presentation calls.  This meant that if you tried to run Teamprise under a x64 Java runtime we died pretty quickly.  We've had x64 support available for other platforms for a while (including Linux), but with Windows x64 support coming in Eclipse 3.4 we took the opportunity to compile our JNI code over to the Win32 x64 architecture and it works great.

On a personal note, during this activity I had to fix some bits in the core Eclipse 3.4 codebase (specifically PDE for people that are interested) and the small patches that I submitted have been applied into the main Eclipse project which is a nice feeling. Eclipse is a poster-child of open source projects and it is with some pride that I can tell people I have contributed code into it. It's also nice that as Teamprise is a commercial company that uses a lot of the Eclipse code and is an Eclipse Foundation member, we are able to do our bit and contribute something back for the benefit of all.

As you can see, we've been busy. We've hopefully cleared some adoption blockers for some of our customers, done quite a few bug fixes and performance improvements and thrown in some new features along the way.  While the headline grabbing features of interest to most people are probably the offline support and the 64-bit support, I'm very proud of this as a solid "point" release and I would encourage everyone with a valid 3.0 license to upgrade.

I am proud to announce that Microsoft have just published a joint case study with us on the success Thomson Reuters have had using Team Foundation Server in a mixed development shop.  This customer is particularly interesting, not just because they keep giving us great feedback on our product that we have been incorporating into Teamprise, or because they are a large, well know and well respected brand.  From the case study;

"The Online Services group at Thomson Reuters is responsible for the storage and retrieval of online assets. Of the 220-member team, approximately 150 are development engineers or quality engineers. Although the team does some programming using the Microsoft® .NET Framework, the group primarily develops in Java on computers that run a variety of operating systems, including Linux, Linux 64, UNIX, Macintosh, and Windows®. About 90 percent of the programmers in Online Services work in Eclipse or Rational Application Developer (RAD), and up to 50 percent of the testers work in Eclipse. All of the team’s build computers run UNIX or Linux."

Anyway, thanks to Mac and the people at Thomson Reuters for agreeing to share their experiences.  Hopefully other organizations considering Team Foundation Server to manage the whole software development process will find the case study interesting.

To read the case study in full, see Microsoft Case Studies: Thomson Reuters Unify Development Processes with Team Foundation Server and Teamprise.  I've also got a PDF version available here.

I've been doing a lot of work with the Team Foundation Server 2008 SP1 Preview, and even recorded a podcast about it (also see Brian Harry's blog post for more details on TFS 2008 SP1 features).

One out of the many new features introduced in TFS 2008 SP1 is the "Last Check-in" column in the source control explorer. It is a handy little thing that I think a lot of people will find useful. 

However just a couple of warnings for you for behaviour that you might not expect at first.

1. The date shown for folders is the date that the folder was added, not the last date that any contents of that folder where checked in.  That means you cannot use it to drill down onto the most recently changes files - to find that out you should still do a "View History" on the parent folder and look at the changesets.
2. If you are using a Visual Studio 2008 SP1 client (or Teamprise 3.1 for that matter when it is released) and you point it at a server prior to TFS 2008 SP1 (i.e. TFS 2005 or the RTM release of TFS 2008) then you do not get any data in this column because the server doesn't send back that data to the client.

Otherwise it works pretty much as you expect.  Most useful is that you can obviously sort the column to find the recently changed files in a big list of files.

Infragistics is the world's largest publisher of reusable presentation layer development tools for Windows Forms, ASP.NET, WPF, Tablet PC and Java (JSF) environments.  I think they can count most of the Fortune 2000 as customers of theirs.  They also happen to be a customer of ours. 

I was in an email discussion with fellow MVP Ed Blankenship, when he came out with the following quote which Infragistics have kindly given me permission to share.

“We completely use Microsoft® Team Foundation Server (with Teamprise) for the development of all of our products now.  This was especially challenging with bringing in our Java (JSF) development group into the same development process of our .NET product lines.  By leveraging the Teamprise Eclipse plug-in and the ANT Team Build tasks, we were able to ensure they were using the exact same systems as the other departments in Engineering.  So the JSF team now has access to the same build, version control, work item tracking, and other internal automated software solutions that the rest of our company uses.  Visual Studio® Team System has really enabled us to solidify our internal ALM process, metrics gathering, and reduce overhead from supporting different systems across product teams.”

Ed Blankenship
Infragistics

Thanks for sharing Ed!  On a personal note, I'm glad that the Ant integration is proving so useful to many companies and this is an area that we are going to continue investing in along with everything else.

At EclipseCon 2008 this morning, we just announced that Teamprise 3.0 has been released!  If you've been wondering why I have been quiet on the blog lately - but also why anything I have been talking about is Team Foundation Build related, then you are about to find out why :-)  First of all, I'd encourage you to go visit the shiny new website at http://www.teamprise.com.  Our marketing team had too much fun putting that together, including getting a real, live, massive Teamprise power button made up and shipped in a huge crate from New York to be photographed and used as the new site/icon image.

The full release notes are available here, but as has been the tradition for the past few Teamprise releases, I thought I would give you a run down of my favourite new features in the 3.0 release.

At a high level, the features in 3.0 can be summarised as:-

• Full Team Foundation Build integration (including ability to execute Ant based builds)
• Check-in policy support
• Recursive folder compare
• Single sign-on (from Microsoft Windows machines)
• "Destroy" command for version control
• Show deleted items and undelete from Source Control Explorer UI
• much much more (see release notes)

While it is not my area, I should also mention that we've taken this opportunity to make our licensing more affordable for smaller teams.  We have been very pleasantly surprised by the number of people buying 1 to 20 licenses at a time.  Originally, Teamprise pricing was skewed to the Enterprise customers (i.e. simple, all inclusive and with steep volume discounts).  So we have done a couple of things to help out the smaller companies:-

• You can now purchase the various components (Teamprise Plug-in for Eclipse, Teamprise Explorer, Teamprise Command Line Client) individually as well as the Teamprise Client Suite which gives you the lot.
• We have lowered the initial prices for a single seat, meaning that people buying one or two licenses can now get the same discounts that used to only be available to folks purchasing 100.

If you have any licensing issues / queries then feel free to contact me, or you can talk to the sales team direct at sales@teamprise.com.  Anyway - back to the part of this release that I do know about - the technology. 

The first feature I want to talk about is one that I had no involvement with.  It's one of those features that many people will not notice because it just works but anyone who has done any Java to .NET web service interop work will instantly recognise as being a little bit clever.

Single Sign-On

The initial log-in screen has undergone a big overhaul.  On Windows machines you are given the option to use "default credentials", i.e. the username and password that you are logged onto windows with.  It obviously doesn't know your password, but does some JNI magic to get the native Windows API's to handle the authentication logic with Team Foundation Server.  While you are also on the login screen, you may notice the Profile feature.  This is an area that many people probably won't use, but we added for our power users and for ourselves.  Basically, the profiles feature allows you to store sets of servers/credentials that you commonly use to connect to Team Foundation Server and then you can bring up the details using a simple drop down.  Makes it much easier to switch between your production TFS instance and your CodePlex project for example - or switch credentials if you are a TFS administrator.

Check-in Policy Support

In Visual Studio, check-in policies are implemented as a .NET assembly runs every time a policy is evaluated or configured.  The policy also has full access to the .NET API's, the Visual Studio API's as well as anything it might want to pinvoke out to on the Win32 API side.  As you can imagine, this presented us some problems when we wanted to have check-in policies that ran the same in Eclipse on Windows Vista as Teamprise Explorer on the Mac or Aptana on Ubuntu - therefore we have had to develop a parallel Teamprise check-in policy framework.

As we were doing this, we took the opportunity to learn from some of the feedback folks have been having with the Visual Studio check-in policies.  While our framework and SDK will look very familiar to anyone that has developed a custom check-in policy for Visual Studio, you will notice some differences.

Firstly, we supply different policies out of the box.  The vast majority of custom check-in polices that people deploy are things like "Check for Comments" etc, so we just shipped the common ones our customers wanted to prevent them from having to write their own.

Secondly, we make use of the Eclipse plug-in framework to implement our policies as extension points.  This means that they are easy to deploy (using the Eclipse update site mechanisms built in to the IDE).  We have also separated the configuration (stored as a blob of XML data in our framework) from the implementation - represented by the plug-in deployed.  The again makes it easier to deploy, especially when it comes to version 2 of a policy...

Thirdly, all of our policies can be scoped by the path in version control to which they correspond - you are not limited to per Team Project scoping and you do not have to wrap your policies in a custom policy to get more detailed scoping like you do with the current Visual Studio framework.

Team Foundation Build Integration

Anyone that has been following this blog for a while, or who attended the Team Build talk I did at TechEd with Brian Randell, will notice that I have been increasingly involved in the inner workings of Team Foundation Build.  Now you can see the fruits of that labour.

In Teamprise we now have full integration with the shiny new build functionality in TFS 2008 as well as support for TFS 2005.  Backwards compatibility with the TFS 2005 server is very similar to if you were using a Visual Studio 2008 client, accept that ours is slightly more backwards compatible (you can create new builds on a TFS 2005 server as well as manage build qualities etc).  However it is with TFS 2008 that you get to see the majority of the features.  I could go on about this aspect all day as their are so small things that I am proud of, but at a high level you can:

• View existing build definitions
• Manage builds in Build Explorer
• Queue new builds
• View build report
• Edit Build Quality
• Delete build
• Manage Build Qualities
• Open Drop Folder
• New/Edit Build Definition

• Edit Retention Policies
• Keep Build
• Set Queue Priority
• Postpone Build
• Stop/Cancel Build
• Delete Build Definition

One of the smaller features I will call out is that from the build definition in the Team Explorer, you can right click and do a "View Build Configuration" that will open the Source Control Explorer at the place in which the TFSBuild.proj file is stored so that you can check it out and edit it.  A feature that I added solely for my own sanity during dogfooding :-). 

All this would be fairly academic, if you didn't have some way to do a cross-platform build using Team Foundation Build.  In the current release, we provide a the Teamprise Extensions for Team Foundation Build which basically Ant enables the Team Foundation build server.  The Teamprise extensions are a set of MSBuild targets that insert the Ant build process into the standard Team Build mechanism as well as a custom MSBuild We hope to extend this to support in the near future to some of the other common build/test tool-chains in the cross-platform world.  However, the Ant integration case will help a lot number of people out there.

Best yet, the Teamprise Extensions for Team Foundation Build are available free of charge for everyone - wether or not you are a Teamprise customer.  Also, if you want to see how they work and customize them to meet your own non-standard build system then the source is available under the permissive open source Microsoft Public License (MS-PL).

I would personally like to thank the Team Foundation Build Team (especially Buck Hodges and Aaron Hallberg) who have been incredibly helpful through the development of the build functionality in Teamprise 3.0 while they were also busy working on TFS 2008. 

Hopefully that gives you a quick flavour of Teamprise 3.0 and where we are going with this release.  If you head over to the new site now and take a look at the many improvements we've made, we'd love to hear what you think.

Paul Hacker, Mickey Gousset and I have recently started a Team System related podcast called Radio TFS.

While it is not going to win any awards any time soon, we've been having a lot of fun so we are going to continue to try and get one or two episodes out a month. If you have 40 or so minutes to kill, then feel free to take a listen and subscribe.

If you have any suggestions for topic or any questions about Team System that you would like answered then please drop us a line at radiotfs@gmail.com or visit the website at http://www.radiotfs.com.

In a previous post, I talked about how Windows file sharing sucks over the WAN. This is particularly annoying for me when trying to view the log of a TFS Build - especially if that build has failed and I want to know why in a hurry. On my computer (sitting on the end of a VPN nearly 4000 miles from my TFS instance), there is a delay of about 50-70 seconds to view the log file depending on the size and the speed of the link at that moment in time.  During that time, Visual Studio is hanging waiting for the file to open.  The issue is compounded by the fact that the rest of the Team Build UI - and in fact the whole of TFS access in general - is so speedy over the same VPN link, that I really notice the time delay accessing build logs.

Therefore - it didn't take too many 70-seconds delays for me to fire up a second instance of Visual Studio to create a work-around.  In Visual Studio 2008 (and in the upcoming Teamprise 3.0 Team Build integration), if the log location provided is not a UNC style path (i.e. \\server\drop\build\BuildLog.txt) but a http:// address, then it will open the file in a browser instead.  Accessing the build log over http helps in two important ways.

1. HTTP is much less latency sensitive than accessing a file from a Windows share
2. A browser will display the contents of the file before it has finished loading.  When accessing the build log directly from a file share, the application (i.e. Notepad) will have to wait until it has recieved the whole file before displaying any of it to you.  These log files can get large - so the improvement in perceived speed is significant. (http:// urls are a lot more cross-platform friendly than UNC paths as well, which is nice for us Teamprise folks).

Therefore, I created  a quick and dirty ASP.NET page that accessing the build log for a particular build over the network and streams the contents of a build log to the browser.  I then add a target into my TFSBuild.proj file that sets the log location to be the http url rather than the default UNC address.

LogView ASP.NET Page

I am by no means an ASP.NET expert - so please feel free to highlight any glaring stupidity on my part if you know better.  I know the code below is sub-optimal and presents some security considerations, however it is a quick work-around that I spent a couple of minutes over to solve my issue - so please treat this code as just that.

Create a new Web Application Project, with references to Microsoft.TeamFoundation.Client and Microsoft.TeamFoundation.Build.Client assemblies.  Create a new aspx page - mine is called view.aspx.  In the page mark-up, ensure it only contains the Page tag, and an output caching directive.  Mine (which is in a C# project) looks like this.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="view.aspx.cs" Inherits="LogViewer._Default" %>
<%@ OutputCache Duration="2592000" Location="Server" VaryByParam="*" %>

Now - the work is performed in the code behind.  

  1 using System;
  2 using System.IO;
  3 using Microsoft.TeamFoundation.Build.Client;
  4 using Microsoft.TeamFoundation.Build.Common;
  5 using Microsoft.TeamFoundation.Client;
  6 
  7 namespace LogViewer
  8 {
  9     public partial class _Default : System.Web.UI.Page
 10     {
 11         protected void Page_Load(object sender, EventArgs e)
 12         {
 13             Response.Write("<html>");
 14             string teamFoundationServerUrl = Request.Params["TeamFoundationServerUrl"];
 15             string buildUri = Request.Params["BuildUri"];
 16 
 17             if (String.IsNullOrEmpty(teamFoundationServerUrl))
 18             {
 19                 teamFoundationServerUrl = "http://localhost:8080";
 20             }
 21 
 22             if (String.IsNullOrEmpty(buildUri))
 23             {
 24                 Response.Write("<title>LogViewer Error</title><body>A valid BuildUri must be passed</body></html>");
 25                 Response.End();
 26                 return;
 27             }
 28 
 29             TeamFoundationServer tfs = new TeamFoundationServer(teamFoundationServerUrl);
 30             IBuildServer buildServer = (IBuildServer) tfs.GetService(typeof(IBuildServer));
 31 
 32             IBuildDetail buildDetail = buildServer.GetBuild(new Uri(buildUri));
 33 
 34             String logFile = Path.Combine(buildDetail.DropLocation, BuildConstants.BuildLogFileName);
 35 
 36             Response.Write("<title>Build Log: " + buildDetail.BuildNumber + "</title><body>\r\n<pre>");
 37 
 38             StreamReader reader = File.OpenText(logFile);
 39             String line = reader.ReadLine();
 40             
 41             while(line != null)
 42             {
 43                 WriteLine(line);
 44                 line = reader.ReadLine();
 45             }
 46             reader.Close();
 47             
 48             Response.Write("</pre></html>");
 49 
 50             Response.End();
 51             
 52         }
 53 
 54         private void WriteLine(string line)
 55         {
 56             line = Server.HtmlEncode(line);
 57             if (line.StartsWith("Target &quot;"))
 58             {
 59                 line = "<strong>" + line + "</strong>";
 60             }
 61             Response.Write(line);
 62             Response.Write("\r\n");
 63         }
 64     }
 65 }
 66 

As you can see - this is a very quick and dirty example.  I am relying on the output caching of the ASP.NET page to provide any performance at all, and this code could be improved in many ways.  However to walk you through the code;

I start by checking for a TeamFoundationServerUrl parameter, if not passed, I assume that this application is being installed on the TFS server itself so localhost:8080 will get me there. I show an error if the BuildUri is not passed.  Inside the TFSBuild.proj file execution, the MSBuild properties $(TeamFoundationServerUrl) and $(BuildUri) are accessible and provide you all you need to be able to get how of the build that you are building.

Line 29 is me getting hold of the TFS instance, line 30 the build server and finally line 32 the build that I am currently executing.  3 lines to get everything I need to be able to query and modify the build information - you gotta love the TFS2008 build API ;-)

I then (line 34) get the build log path, which is always a file called BuildLog.txt in the drop folder.  I then simply stream the file, line by line, into the response stream.

The WriteLine method is used to do this so that I can optionally do a bit of formatting to the lines as I stream them to the client.  In this example, I am highlighting and lines that are the beginnings of a Target - just to make the log easier to read.

I then deploy this ASP.NET page onto an IIS server.  In my case, I have it running on my production TFS server as a separate application (on a different port) and I have the application set to run as a defined user that has read access to the drop share along with read access to the TFS Build Store.  This means that anyone inside the network can anonymously access the web page and view the build log of any build - but that is acceptable in my organization.  You might want to make access more secure - but then you will also have to be cleverer in your output caching decisions.

TFSBuild.proj File Customization

In the TFSBuild.proj file, I then override one of the provided hook targets to set the log location property of the build.  I'm still un-decided as to which is the best target to put this in, but at the moment I'm going with BeforeGet.

As you can see - it is pretty low tech, but very effective.  Clicking on the link starts providing me with log output with-in a second.

I actually have the web site running on port 9090 configured to give me directory browsing of the drop location file share (that is also located on the same server).  This means that I can access my drop files using a browser by browsing to http://tfsserver:9090/ - however, you can not update the drop location of the build to be a http:// url.  This is because the drop path is specified (and verified) as a UNC path and several parts of code in the build client API itself assume this.  You could work around this by extending the ASP.NET page mechanism above to provide access to the files in the drop location - perhaps a future project for me ;-)

Rather a lengthy post this one - but I hope it helps someone else out of the same frustrations I was having.  If you've read this far than I guess it was moderately interesting to you :-)

I connect to the central Teamprise TFS instance over a VPN connection to the head office in Champaign, IL.  It is a direct distance of nearly 4,000 miles - but probably much longer depending what route my packets take - on a good day typical ping times for me are ~150ms, but bandwidth is also a major issue.  On my current ADSL line (that is booked in for upgrade before the end of the month) I get 140 kbs upstream and about 400 kbs downstream - on a good day.  On a bad day, it can be much worse.  Last year someone decided to start shooting at bits of fibre optic cable in Ohio and that really messed up my day.

In many ways, the fact that Teamprise has a couple of the core development team working remotely over the VPN is good for Teamprise the product because we certainly complain if we encounter any performance issues during dogfooding - issues that the folks in the office with a gigabit connection to the TFS server might not feel as strong about :-)

TFS mostly works great for me over my VPN connection.  The TFS team did a lot of work to optimise TFS traffic for WAN environments, such as use of standard web based protocols for transport, the heavy use of compression, minimization of the SOAP payload, keeping connections cached and not to forget things like inventing the TFS Proxy Server - you can certainly tell that TFS was designed with this type of environment in mind.  (I'm sure it helps that the majority of the TFS team are based in Raleigh, NC while their dogfood TFS instance is based in Redmond, WA ;-) ).   The only times where I have issues are on the rare occasion when Windows File Shares are used or the client needs to query Active Directory information.

Obviously - Windows file shares are an issue for Teamprise in general (with around 50% of the team using non-Windows systems as their primary machine).  But most modern operating systems can talk to CIFS based file systems pretty well.  The issue for me is that Windows file shares suck over a high-latency, low bandwidth connection.  This was one of the reasons VSS performed so badly over a WAN.  Thankfully there are only a couple of main areas in Team System and TFS where Windows file sharing is currently used:-

1. Publishing of test results from the client
2. Accessing the TFS build drop location (and most annoyingly, the build log file).

Note, it because of these types of issues (and the Active Directory releated ones) that I always recommend people connecting into TFS remotely use a VPN if they want access to the full functionality.  While the Windows file sharing bits may perform really badly - at least they will work over a VPN.  Try getting file sharing to work securely between firewalls if TFS is exposed on the internet and a VPN is not used...

In a follow up post, I'm going to be talking about how to modify your builds to make them easier to work with over a WAN / VPN.  Despite these minor niggles (which don't come up very often), if you are considering using TFS for use over a VPN or Wide Area Network then I would certainly recommend it.

I just noticed that on Wednesday January 16th at 5pm, the Minnesota Visual Studio Team System User Group are having a talk by Mac Noland.

Mac is a good guy with some very interesting real-life experience in the use of TFS, and I would expect this talk from Mac to give people a great understanding of TFS could fit in their enterprise - but also a realistic, unbiased, warts and all view of TFS with Teamprise in the real world. 

Should be fun - I wish I was closer as I would love to attend myself.  If you are in the area and can make it along, then here are the details:-

Date / Time: Wednesday, Janurary 16th @ 5pm

Where: Microsoft, 8300 Norman Center Dr., Suite 950, Bloomington, MN 55437

Topic: Thomson's use of Team Foundation Server with Teamprise as a cross platform, integrated Configuration Management solution.

Description:

Thomson's Online Services is responsible for the backend storage and retrieval of online assets.  The Online Services - Quality department has implemented Team Foundation Server (TFS) for the group, which primarily develops in Java on Windows, Linux, Linux64, Unix and Mac.  With the help of Teamprise, Online Services is now able to interact with their configuration management solution (i.e. TFS) from non-Windows environments. 

Online Services has learned some valuable "cross platform" lessons while implementing TFS.  These lessons may benefit others as they start to implement TFS for non-Microsoft development groups.  A sampling of their experience is below.

• Yes, you can use TFS to store non-Microsoft software assets
• Replace multiple bug, change, source management tools with TFS
• Use Team Build for non-Microsoft builds

As a follow up to my post back in August when we put TFS Beta 2 onto our production box, I just thought I'd mention that here at Teamprise we have now been running Visual Studio Team Foundation Server 2008 for over 6 months now.  We recently upgraded our production TFS instance to the RTM release of TFS 2008 and everything is going very well.

The Microsoft team have done a fantastic job with compatibility which meant that we didn't even need to re-compile Teamprise to get it to work with TFS 2008 and still get all the performance benefits from the server.  The current public versions of Teamprise work great with TFS2008, as does Visual Studio 2005.

While TFS performance has improved since the RTM of TFS 2005, for me the single biggest reason to upgrade to TFS 2008 are the new and much improved build capabilities.  As you might have guessed by the number of Team Build related posts on my blog lately - in the next version of Teamprise we will be including integration with Team Build.  This has been my area of focus for most of this year so I am really excited to see what people think once we make it available.

In the meantime, if folks are considering upgrading to TFS2008 from TFS2005 then I would certainly recommend it.  The upgrade from TFS2005 to TFS2008 has been very smooth in my experience.

With the recent release of Microsoft Visual Studio 2008 Team Foundation Server we are seeing more and more people looking to use the build capabilities of TFS (often referred to as "Team Build") to manage their Java based builds as well as their .NET ones.  We have an MSBuild task available internally that we use to trigger Ant based builds and report the progress back into TFS, and I wanted to share this with a wider audience to get some feeedback.  This task is heavily influenced by Aaron Hallberg's Team Build DevEnv task which I encourage you to go look at if you are interested in getting other build systems integration with Team Build.

You can download an early version of the Ant task from here - (TeampriseBuildExtensions 1.1MB).  There are two versions of the task included in the zip file - one for TFS2005 and one for TFS2008.  Additionally there is a draft set of instructions included on how to get this working today.  We hope to make the process much easier with future releases of Teamprise.

The Ant task works by calling Java to run Ant. The task first parses the Ant file to locate the name of the project and the description. It then calls Ant and the resulting output from Ant is then parsed by the task to look for key information (such as javac and junit tasks) as well as to pass the results into the MSBuild log. Options which are normally available via ant launching script are available as additional attributes to the Ant task.

Example Usage

<Ant TeamFoundationServerUrl="$(TeamFoundationServerUrl)" 
  BuildFile="$(SolutionRoot)\java\HelloWorld\build.xml" 
  BuildUri="$(BuildUri)" 
  AntHome="$(ANT_HOME)" 
  JavaHome="$(JAVA_HOME)" 
  Flavor="%(ConfigurationToBuild.FlavorToBuild)" 
  Platform="%(ConfigurationToBuild.PlatformToBuild)"   
  Properties="BinariesRoot=$(BinariesRoot);BuildNumber=$(BuildNumber);SourceGetVersion=$(SourceGetVersion)" />

Task Reference

The following is a complete list of all the attributes supported by the task, note that many of them are best left to the default values unless a different behavior is explicitly required. Items that are in bold are the ones that are frequently used.

As part of the next version of Teamprise we will be providing integration with Team Build in the UI (i.e. inside Eclipse based IDE's or in the stand-alone Teamprise Explorer client).  More on those build capabilities soon - but hopefully you can see that with the ability to run Ant based builds from Team Build and the ability to control/monitor from Eclipse you will have a nice build system that is fully integrated with TFS.

If you find this task useful, then be sure to drop me a line with any feedback you might have.  We have not yet decided how to make the source of this task available, either as an open source project of it's own or as part of a larger community of MSBuild tasks.  There are pro's and con's to both.  In the meantime, if anybody would like the source code then drop me a line.

Ron Jacobs has posted up an ARCast video from TechEd 2007 in Australia.  About 3 minutes in he does a nice interview with an organization using Team Foundation Server in a cross-platform environment.  While I spend a lot of time talking about the performance of TFS over the WAN and extending the benefits of Team Foundation Server outside of Visual Studio by using the Teamprise Clients as well as the Microsoft MSSCCI provider(pronounced "Miss-key") - it is always nice to hear it from real people in a real company....

Anyway - if you have a spare 15 minutes, go take a look.

Brian Harry has posted some great news over on his blog - Microsoft have release a new tool to allow users to migrate from ClearCase to Visual Studio Team Foundation Server.  From Brian's blog:-

A quick summary of the features of the tool:

• Supports migration of base ClearCase VOBs

• Migrate a snapshot of source control to TFS

• Migrate files to Team Foundation Server while preserving history

• Migrate branches to Team Foundation Server retaining the branching structure/hierarchy

• Bidirectional synchronization of data between TFS and ClearCase

Hopefully this will really help people as they move from ClearCase or even people who would like to try TFS in a small isolated team but still synchronize back to the main enterprise ClearCase repository.  Keep an eye on Matt Mitrik's TFS Migration Blog for more details.

Paul Julius just announced that RC3 of CruiseControl 2.7.1 has been released from the Agile 2007 conference.  From my point of view this is fantastic news, because it includes a patch I submitted to the project to include integration between CruiseControl and Team Foundation Server.  Previously this was available from our website but from 2.7.1 onwards it will be included in the base CruiseControl distribution.

If you have an existing CruiseControl build process then this makes it really simple to migrate your source control over to TFS.  Combined with the TFS Ant tasks we make freely available you should be good to go. Note that both the CruiseControl integration and the Ant tasks require a version of the TFS Command Line Client be installed on your build server.  We've tested them against the standard Microsoft tf.exe for Windows build servers and our own tf command line client that works cross-platform.

Thanks to Dan Rollo and the rest of the CruiseControl team for checking over and committing my patch, which got assigned the rather ominous issue number of CC-666 ;-)

Yesterday I sat down with my freshly downloaded Orcas Beta 2 media (thanks to the Secure Content Downloader from the good folks at Microsoft Research in Cambridge) and upgraded our production TFS instance.  The good news is that the set-up process in Beta 2 is miles better than it was in earlier versions of TFS - it even handled the upgrade of my database for me.  As someone who has been through manual database upgrades from TFS 2005 Beta 2 -> Beta 3 -> Beta 3R -> RC -> RTM -> TFS 2008 Beta 1, having it all done for me was just fantastic.

Performance wise, things seem to be a lot better than TFS 2005 SP1.  Other good news is that the existing Teamprise clients (including the recently shipped 2.2 release) versions talk to TFS 2008 just fine thanks to the fantastic work the TFS team have done to ensure backwards compatibility.  Obviously our clients do not yet take advantage of some of the new TFS 2008 functionality - but the performance improvements made on the server definitely come through.

The only minor issue we came across was one to do with our reports being displayed in our WSS 2.0 portal (see Tim Noonan's blog for the fix).

Anyway - thought I'd spread some positive news about the recent TFS Beta, I'll let you know how we get on.