Recently in Vsts Category

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).

Eclipse 3.7 with Team Explorer Everywhere 2010 SP1

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:

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”.

Default Template build process properties shown when editing the build definition in Visual Studio 2010

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).

New Java Project dialog in Eclipse

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:

Eclipse with the TFS SDK in a project

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.

Configuring Java build path in Eclipse

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…)

New Class Dialog

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

Example code in Eclipse

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.

Javadoc for TFSTeamProjectCollection

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.

Professional Team Foundation Server 2010I’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 :-) )

vs2010alm_bookPeople 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.

Team Explorer Everywhere World TourEd 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

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)

One of the key things about your CI build is to ensure that is runs fast so that you have a very quick feedback loop to see if you have a good build or not.  Rob Maher has an interesting blog post up describing how he customized the build process to make use of the test impact analysis feature so that only the impacted tests are run as part of the CI build and then the full test suite run later. 

If your tests take a long time to run, you may wish to only run the tests that have been impacted by code changes checked in with the build (and of course run a full nightly build that executes all tests :) Unfortunately there is no out of the box feature to do this, so we need to edit our build xaml to do it.

TFS 2010 Build - Only run impacted testsRobert Maher

In Rob’s example he uses a nightly build process to baseline the test impact analysis – however this might be a good candidate for a Rolling Build set to run once an hour or so (I personally prefer builds to run when there is someone still at work able to fix a build process should it break).  Anyway, it’s an interesting read not only for the idea but also as a good example of some of the key techniques when customizing a build in TFS 2010.

Archives

Creative Commons License
This blog is licensed under a Creative Commons License.