Recently in tfs Category

I just got delivery of my shiny new Raspberry Pi.  With-in a few minutes I had it all booted and running a stock Debian “squeeze” image, almost too easy and the performance of the diminutive Raspberry Pi was great. Previously my experiences with Embedded Linux has mostly been when running on hacked router firmwares so running on a chip as powerful as the ARM v11 Broadcoam chip in the Raspberry Pi is a real pleasure.  As getting it up and running was so easy, what should be my first project on my latest (and least expensive ever) computer?  I thought I’d see what it took to talk to TFS from the device :-)

First things first, I had to get Java installed.  It sounds like Oracle are working on a version of Java with a proper Hotspot JVM – but I just went with a vanilla OpenJDK build for the device that lacks important features like a JIT etc.  It’s all fully functional, just the performance isn’t great but sticking to the TFS cross-platform command line client (tf) in Team Explorer Everywhere, performance is usable and will only get better as better JVM’s come available for the Raspberry Pi.

To install a JRE you would just do the usual:

sudo apt-get install openjdk-6-jre

However, I needed to do some building on the Raspberry Pi and needed a full JDK so I went with:

sudo apt-get install openjdk-6-jdk

And then set my JAVA_HOME by adding the following to my profile

export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/

Now, I like to say that Team Explorer Everywhere is 99.99% Java.  All the code to talk to the TFS webservices is all Java based, however there is a small but very important set of native code that we also ship with our Cross-platform command line client, the Eclipse plug-in and the TFS SDK for Java.  The native code does things that are hard to do otherwise such as see how many columns are available in the current console session, use Key Ring of Keychain for secure credential storage, interface with the platforms native Kerberos libraries if present to allow for single sign-on with TFS etc.  My next step to get tf working on the Raspberry Pi was to compile our native code for the armv6l based chipset.  As mentioned this native code includes Kerberos support so I first had to add the Kerberos libraries (sudo apt-get install libkrb5-dev - note you wouldn’t have to do this if you didn’t need Kerberos support as we also support NTLMv2 out the box without requiring any additional dependencies)

I ran the native build process, and amazingly all the unit tests passed!  I then checked the Linux/Arm natives back into TFS, waiting for the CI build to finish and then downloaded a new TFS-CLC.zip from the build server.  Unzipped the standard CLC into my users ~/Bin directory and it just worked!

I can now happily talk to my local TFS server from my $25 Raspberry Pi.  With local workspaces and transparent execute bit support in TFS 2012 it’s a really good experience. I just use vim to edit files, do a quick “tf status” to see what's changed and then a “tf checkin” to add the files to source control.

I’ve actually added the Linux on Arm natives into the main build of TEE so they might appear in the RTM version of Team Explorer Everywhere if I don’t find any major bugs.  It definitely wouldn’t be classed as a supported platform or anything, but it certainly “works on my machine”.  Possibly more useful is that if the Arm natives also ship in our TFS SDK for Java it would mean any Java applications coded on the Raspberry Pi in the future would have full access to the same TFS API that we use to create the command line client and the Eclipse plug-ins.

Update: I was getting some questions on Twitter, so just to explain how small this device is here is a picture of it against my Microsoft ID Card (which is credit card sized).  The Raspberry PI is almost exactly the same size.  The ARM CPU on it is about the size of a thumbnail – much smaller than the HDMI and Ethernet connection it is attached to.  Really nice piece of kit for $25 if you can get hold of one.

All this was anti-climatically easy. I’m going to have to figure out what to do as my next Raspberry Pi project.  Now that I have an API I can use for TFS, I’m thinking about doing a Wallboard display application to display stats from my TFS server (such as latest build status, latest check-ins and work item assignments etc) from the device onto a cheap HDMI TV set in my office – but if anyone has any other ideas let me know.

If you are looking to extend Team Foundation Build using workflow activities, then the first thing you should do it take a look at the latest stable release of the Community TFS Build Extensions over on CodePlex.  This is a collection of around 100 activities that can provide many commonly requested functions incluing running CodeMetrics and NUnit tests, creating a Zip archive, wrapping RoboCopy for deployment, updating AssemblyInfo files, running StyleCop, merging assemblies with ILMerge etc etc.  Basically most of the building blocks for major common customization already done for you.  Also – as it’s an open source project ran by the MVP community you have access to a bunch of great code that shows you how to create your own activity should you want to do something that has yet to be done (don’t forget to contribute it back if you can)

Great job to the team of folks contributingg to the community build extensions (many of which I am proud to call my friends) – I’m looking forward to seeing the project go from strength to strength now that they have their first stable release out the door.

As you have probably heard by now, Eclipse 3.7 shipped today.  Congratulations to everyone involved.  From a personal point of view I’m secretly pleased to see that one of my own bug reports manage to sneak it’s way in to this release as well which I think means I have managed to do my bit and contribute a little something to every Eclipse since 3.4

We’ve been tracking the Indigo release internally through the latter milestone builds and so far we’ve yet to discover any issues when using Eclipse 3.7 with Team Explorer Everywhere 2010 SP1 (as many of the team do every day).

Let me know if you think you do find something but as we don’t use any internal Eclipse API’s, we stick to the standard Eclipse contributions and install via the standard update site model - Eclipse 3.7 is looking very good with TEE 2010 SP1.

I’ll be showing off Team Explorer Everywhere 2010 SP1 in Indigo at the following events over the next few days:

• Jazoon 2011 (Thursday, 23 June 2011, 10:30-11:20)
• Eclipse DemoCamp Indigo 2011, Amsterdam (Tuesday 28 June 2011, 17:15-18:00)

When you create a new build definition with TFS 2010 by default it does a clean build for you every time.  That is to say that between builds all the source from the previous build is deleted along with the compiled outputs and then the source is downloaded fresh, built and you are good to go.  There is a good reason for this to be the default – it is the safest option.  If your build script messes around with the files in your source directory at all (perhaps baking in a build number into the AssemblyInfo files etc) then you want to get a clean workspace to ensure that you are back to a known good state.

However, if you know what you are doing then there are couple of really good reasons why only building the things that changed between builds would be very useful:

1. Speed – if you are doing CI builds (which you should be doing if you are not BTW) then the only thing that will have changed between builds to the same build agent are the contents of a single check-in – a single changeset.  If you are checking in regularly (which you should be doing BTW) then these changesets usually contain a small number of changes.  Downloading only the files that have changed between builds speeds things up but also only compiling new versions of assemblies that have been affected saves even more time.
2. Differential Deployment – For websites it makes a lot of sense to use something like robocopy to deploy the output of a build to a directory used by a test IIS instance.  By using robocopy you can specify that only the files that have changed should be copied over.  When TFS does a get into a clean workspace the files did not previously exist in that location on disk.  Therefore the creation date and modification dates of the source files are taken as the time at which they are downloaded to the machine – i.e. the time of doing a get.  By switching to incremental builds files which haven’t been touched are left alone so older files keep their timestamps.  Only the changes files have a new timestamp.  Utilities such as robocopy can therefore easily identify these and therefore only deploy the changes files over to IIS.  IIS then sees that the file is new and so compiles it first time that page is accessed or a page references an assembly that has been updated.

Traditionally, in the world of build solutions, incremental builds were always treated with a bit of “Here be dragons”.  Many version control systems can leave orphan files around in your local working copy when you update to the latest version from the server (for example in the case that a file was deleted, moved or renamed on the server).  TFS however cleans up your workspace as you go along so that when you do a get deleted files are deleted from your local file system, as are the old versions when you do a rename/move etc.

Enabling Incremental Builds with TFS 2010

To enable incremental builds, edit the build definition in Visual Studio 2010 and set the Clean Workspace property to “None”.

Note that there are a few options for Clean Workspace, All; Outputs; None – take a look at the handy property help text to learn more about what they mean. For example Outputs is useful if you want the benefit of not downloading all your source every time but are not able or do not trust the ability to incrementally compile your binaries.

Your mileage may vary depending on your build process and what you do during it.  Depending on assumptions made during and build customization work you have done you may indeed need to re-engineer the way that you do your build to be able to reap the benefits of incremental builds.  Also, you may want to do things like incremental builds to a dev test instance but a full clean build for your nightly drop to a QA test environment.  Also remember that even with a CI build set for incremental builds, you can at any time Queue a manual build from Visual Studio by right clicking on the build definition in Team Explorer.  From there you can (if you wanted) set the Clean Workspace property to All for your manual build if something funny was going on and you just wanted to reset everything – and if you are really fancy you might even do it so that a deployment of a clean build to IIS not only copies all the files over fresh but forces an IIS Reset for the true belt and braces approach.

As you may have read over on Brian Harry’s blog, we recently made available a TFS SDK for Java.  This is the same core code that we use in Team Explorer Everywhere 2010 SP1 to talk to TFS from Eclipse and from our Cross-platform command line client – just packaged up into a single jar file to make it easier to consume and re-distribute in your own applications.

The TFS SDK for Java ships with a bunch of sample applications, check-in policies, custom work item controls and some handy snippets of code.  It also includes an Ant build script to allow you to build the samples that we ship.  However – I thought it would be interesting to walk through how you can consume the SDK in a simple Eclipse project and make use of some of the nice Eclipse features such as inline Javadoc.

To begin, download the TFS SDK for Java 10.1.0 from the download site and unzip it to a handy location. Next create a new blank Java project in Eclipse (File, New, Java Project).

Give the project a name (i.e. com.contoso.tfsplay), then press Finish to create the empty project.  The next thing that we are going to do is browse to the empty project in the file system to copy over the relevant files in the SDK.  Having the SDK as part of your Java project makes it much easier to build and deploy it later.

First of all, browse to your Eclipse workspace folder in the file system (for example mine is at C:\play\tfssdk4j\com.contoso.tfsplay but you can find where yours is by right clicking on the project you just created and selecting properties).  Inside the project folder, create a new folder to hold your TFS SDK bits.  Mine is called tfssdk at the root at the folder.  Inside this copy the redist folder from the TFS SDK ZIP archive.  I also personally ZIP up the Javadoc folder from the TFS and also include it – however if you have a copy of the TFS SDK Javadoc installed on an intranet server somewhere you could just point to it later on.

Now that we have the SDK inside our project, if I press refresh back in Eclipse on the package explorer I get something that looks like the following:

Now we want to configure the project to include the SDK in it’s build path. Right click on your project, select Properties, then Java Build Path.  In the Libraries tab press Add JAR… Select the com.microsoft.tfs.sdk-10.1.0.jar file from your tfssdk/redist/lib folder.  Now that the JAR file is included, we want to expand it to let Eclipse know about the Javadoc and the natives.  Double click on the Javadoc location and point it to where the TFS SDK Javadoc is located.  Do the same for the natives for your platform.

Your JAR file definition should then look like the above and you are now up and ready to start talking to TFS via the SDK in your Java project.

For our example, let’s create a quick class with a main method. (Right click on the project, New, Class…)

Then inside the main method, I’ll quickly steal the code that Brian used in his TFS SDK for Java announcement blog post. 

Once the code is included and modified to point at my TFS project collection, I’ll quickly debug the code (Run, Debug As…, Java Application…)

I’ll be posting more samples shortly, but now the code is running let’s step through it.  To begin with we first need to get hold of a project collection. In Brian’s example he uses:

TFSTeamProjectCollection tpc =
            new TFSTeamProjectCollection("http://tfs2010:8080/tfs/DefaultCollection");

The reason this works is that the native code libraries are configured correctly so the SDK can then get the credentials of the logged in user and use those to authenticate with TFS.  However – what if you don’t want to use those credentials but want to pass them in via code?  Well luckily the TFSTeamProjectCollection has lots of overloads including one that allows you to pass username, password and domain.

TFSTeamProjectCollection tpc =
            new TFSTeamProjectCollection("http://tfs2010:8080/tfs/DefaultCollection",
                    "username","domain","password");

In our example, we now want to query work items – so we get hold of a work item client as follows:

WorkItemClient workItemClient = tpc.getWorkItemClient();

We then create the query that we want to run.  In the example we’re going to execute an ad-hoc query in TFS’s Work Item Query Language (WIQL).

// Define the WIQL query.         
String wiqlQuery =
    "Select ID, Title from WorkItems where (State = 'Active') order by Title";

// Run the query and get the results.         
WorkItemCollection workItems = workItemClient.query(wiqlQuery);

Finally, we then need to loop over the collection of results and display them.  The WorkItemCollection class contains logic to efficiently handle large result sets.  It will page in a set of query results as needed rather than waiting for all the results to be returned before you can start iterating over them.  This makes it much more efficient if you just need a page of data – i.e.

final int maxToPrint = 20;

for (int i = 0; i < workItems.size(); i++)         
{
    if (i >= maxToPrint)             
    {
        System.out.println("[...]");                 
        break;
    }
    WorkItem workItem = workItems.getWorkItem(i);
   
    System.out.println(workItem.getID() + "\t" + workItem.getTitle()); 
}

The full code for the QueryWorkItemExample is below.  Hope that is makes a bit more sense now that we’ve walked through it.  

package com.contso.tfsplay;

import com.microsoft.tfs.core.TFSTeamProjectCollection;
import com.microsoft.tfs.core.clients.workitem.WorkItem;
import com.microsoft.tfs.core.clients.workitem.WorkItemClient;
import com.microsoft.tfs.core.clients.workitem.query.WorkItemCollection;

public class QueryWorkitemExample {

    /**
     * @param args
     */
    public static void main(String[] args)
    {
        TFSTeamProjectCollection tpc =
            new TFSTeamProjectCollection("http://tfs2010:8080/tfs/DefaultCollection",
                    "username","password","domain");
       
        WorkItemClient workItemClient = tpc.getWorkItemClient();
       
        // Define the WIQL query.         
        String wiqlQuery =
            "Select ID, Title from WorkItems where (State = 'Active') order by Title";
       
        // Run the query and get the results.         
        WorkItemCollection workItems = workItemClient.query(wiqlQuery);

        System.out.println("Found " + workItems.size() + " work items.");
        System.out.println();
       
        // Write out the heading.         
        System.out.println("ID\tTitle");
       
        // Output the first 20 results of the query
        final int maxToPrint = 20;
       
        for (int i = 0; i < workItems.size(); i++)         
        {
            if (i >= maxToPrint)             
            {
                System.out.println("[...]");                 
                break;
            }
            WorkItem workItem = workItems.getWorkItem(i);
           
            System.out.println(workItem.getID() + "\t" + workItem.getTitle()); 
        }
       
        System.out.println("Done");
    }

}

In future posts I’ll talk about how to do more advanced things in Java against TFS.  If you have any requests then please drop me a line, but for now take a look at the snippets that we ship in the SDK.  I’ll also be posting walkthrough posts discussing custom check-in policies in Team Explorer Everywhere, custom Work Item Controls as well as other ways of extending Team Explorer Everywhere and using the SDK.  Again – if you have anything in particular that you’d like me to use as an example then let me know.

I’ve always wanted to write a technical book and when I started getting involved in Team Foundation Server I thought that this technology area might be my chance.  I was lucky enough to get involved with the Professional Application Lifecycle Management with Visual Studio 2010 book and contributed to the TFS chapters in that one – but I knew I had one more book in me.

Luckily, the ALM book was so popular that the publishers came back for more and so I was able to get involved in the book I’ve been wanting to write for the past 6 years.  Not only that, I got to work with Grant Holliday, Ed Blankenship and Brian Keller who are three of the people I regularly turn to for advice on TFS matters.  Having those guys on board made it hard when looking for technical reviewers but luckily Mickey Gousset and Steve St Jean agreed to help out and so the journey began in creating the TFS 2010 book which is now available on Amazon.com (both in paperback and Kindle versions) and available for pre-order on Amazon.co.uk.  As with the ALM book there is a DRM Free eBook available at the Wrox site if you prefer but I’ll also expect electronic versions to be available in all the popular eBook stores in due time.  One neat thing about buying the electronic version of the TFS Book for devices that have a color screen is that in many versions the diagrams and screenshots are in color (which helped me when talking about Branch Visualization or the build reports :-) )

People have asked us what’s the difference between the ALM book and the Pro TFS book.  The ALM book was deliberately written as an overview to the huge amount of functionality available in the entire Visual Studio Application Lifecycle Management suite.  Though there are a couple of chapters, the Team Build one in particular, that get pretty technical – the Pro ALM book tries to keep things approachable by everyone.

The Pro TFS 2010 book is a deep dive on TFS.  We tried to make it so that you can pick up the book having never used TFS before any by the end of it not only know how to use TFS but how to administer a complex TFS instance and even use it to study for the TFS Administration exam.  I’ve learnt something from every single chapter in the Pro TFS book, but I would also hope that someone new to TFS could pick up the book and learn just enough to get going then come back for more over time.

Anyway – while I’ve seen the PDF version of the book and enjoyed reading the chapters contributed by my co-authors, I’m looking forward to getting my physical copy soon from the publisher.  If you happen to get a copy then be sure to let me know what you think.  If you wanted to splash out and get the complete reference set then my personal recommendation would be to get the ALM book, the TFS Book and the excellent Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build (2nd Edition).

Hope you enjoy it anyway – I’m proud of this one so looking forward with nervousness to see what the reviews are when they start coming in.

Ed Thomson from the Team Explorer Everywhere team is going to be doing a tour of the mid-west and central United States in early April.  For those of you who don’t know Ed, he is one of the original Teamprise developers that came over to Microsoft after the acquisition and now one of the core developers on Team Explorer Everywhere.  He knows more about the inner workings of our Eclipse integration than anyone else on the planet.

While he’ll be speaking at a lot of user groups and Microsoft events in various cities, places are filling up fast.  However there is still some availability in a few cities.  If you are nearby or know someone who is then I encourage you to register and come along.

Austin TX

• Monday April 4 (Information)

Minneapolis

• Wednesday April 6 (Details soon)

Chicago

• Thursday April 7 2:00pm – 4.30pm (Register)
• Thursday April 7 6:30pm - 8:30pm (Register)

Milwaukee

• Friday April 8 9:00am – 11:30am (Register)