Team Foundation Server for everyone, everywhere…

The topic I chose to present for this round of Dev4Devs Cape Town was (you guessed it) TFS.
This time I took a different approach and showed off the “new” focus that Microsoft has started adopting. Instead of trying to convert everybody to the Microsoft way of doing things, Microsoft is starting to adopt the desperate development realms and in some cases, is actually supporting them! This is very exciting for everyone using very competent, often “lower cost to entry” development tools and technologies, providing capability to grow which was previously unrealised.

So without further delay – here is a brief overview of my presentation: TFS for everyone, everywhere

IDE of choice…

Anyone who has worked with TFS should be familiar with Team Explorer. This is the developers portal into “the belly of the beast, erm TFS”.

Maybe a little less known to the Java, and especially the Eclipse developers would be a product  by the name of Team Explorer Everywhere (TEE).
This is (amongst others) an Eclipse plugin which is basically Team Explorer for the “non-Microsoft” orientated. It introduces TFS to the Windows, Linux, Mac, Solaris, AIX and HP-UX users (see here under system requirements for the “official” list of supported IDE’s and OS’s).

Deja vu?

As would be expected there are a few minor differences between the two, but by far any Visual Studio / Team Explorer user will feel right at home using and configuring TEE, right down to the check in dialog and policies.

API of choice…

OK, so now you have TFS integration into Visual Studio and Eclipse. What about the extensive .NET API (that is installed with Team Explorer)?

No Problem! Microsoft has released a TFS Java SDK.

Looking at a .NET example to create a work item in TFS:

1) Add a reference to Microsoft.TeamFoundation.Client and Microsoft.TeamFoundation.WorkItemTracking.Client

2) Establish a connection to the appropriate TFS Project Collection

   1: //get default credentials

   2: var credentials = CredentialCache.DefaultNetworkCredentials;

   3:  

   4: //connect to TFS project collection 

   5: TfsTeamProjectCollection collection = new TfsTeamProjectCollection(new Uri("http://localhost:8080/tfs/defaultcollection"), credentials, new UICredentialsProvider());

   6: collection.EnsureAuthenticated();

3) Using a Service Locator pattern we can get “services” from the project collection. In this case we are interested in the WorkItemStore. This is basically a repository for work items and can be used to load and query work items

   1: var workItemStore = collection.GetService<WorkItemStore>();

4) Then a bit of plumbing… Because each team project is based on a specific process template we need to get a work item definition that is appropriate to that project/process template. In this case we are looking for the “Task” work item definition in the “Dev4Devs” team project

   1: var project = workItemStore.Projects["Dev4Devs"];

   2: var workItemType = project.WorkItemTypes["Task"];

5) Create a new work item and start setting appropriate properties

   1: var workItem = new WorkItem(workItemType);

   2:  

   3: //set appropriate properties on the work item

   4: workItem.Title = "my new work item";

6) And finally, based on an active record pattern, we simple save the newly created work item

   1: workItem.Save();

Simple enough…..

So looking at the Java SDK, how difficult will it be?

1) The first step is to obviously get hold of the Java SDK and add it as a referenced library in the java project

2) Create a connection to the team project collection

   1: TFSUser user = new TFSUser("useraccount");

   2: TFSTeamProjectCollection collection = new TFSTeamProjectCollection("http://localhost:8080/tfs/DefaultCollection", user, "Password");

   3: collection.ensureAuthenticated();

3) Get the work item client (instead of store…)

   1: WorkItemClient workItemClient = collection.getWorkItemClient();

4) Get hold of the work item definition from the appropriate project

   1: Project project = workItemClient.getProjects().get("Dev4Devs");

   2: WorkItemType type = project.getWorkItemTypes().get("Task");

5) Create a new work item

   1: WorkItem workItem = workItemClient.newWorkItem(type);

   2:  

   3: //set appropriate properties on the work item

   4: workItem.setTitle("my new work item from java");

6) and finally

   1: workItem.save();

So, save a few nuances, pretty much the same when it comes to the interface exposed by the .NET and Java object models.

As mentioned earlier, I can’t wait to see where all this leads to in the adoption of TFS as a decent (and more often than not, cheaper) ALM suit.
Team Foundation Server…. not just your average version control