Recently in tfs2008 Category

In my inbox this morning I got news of another new version of the Team Foundation Sidekicks from Attrice.  I recommended these tools to several people during the recent TechEd EMEA event in Berlin and so it is great to new tools being added all the time.

With this release we conclude support for Visual Studio/TFS 2005 & 2008; from now on any future releases will target VS/TFS 2010. Sidekicks version for 2010 (based on Beta 2 bits) may be expected by the end of 2009.

The release 2.4 includes a relatively large number of bug fixes as well as couple of new features.

Features

• Labels Sidekick: Support filtering by file extension in Labels Comparison window
• Code Review Sidekick: Check-in policy violation indication shown next to changesets in a list
• Workspace Sidekick: Support ability to save list of found workspaces
• New Users View Sidekick: Show searchable list of user names and user display names in TFS Valid Users group

Team Foundation Sidekicks 2.4 release – Attrice

As a reminder, the sidekicks are an excellent and free add-on to Team Foundation Server.  They make up an essential part of my toolkit.  I’m also pleased to see that they are going to be looking into tools for the TFS2010 stack later in the year, bodes well for TF Sidekick support of TFS 2010 soon after release.

A feature of changeset metadata in Team Foundation Server 2008 is that it is actually editable.  If you look at the changeset details for a historical check-in in Visual Studio you will notice that the comment and check-in notes fields are enabled and there is a “Save” button. This is by design, but I have known customers that find this fact very surprising. 

In fact people are so surprised that this is even possible that in Teamprise we currently do not provide a way to edit the comment or check-in notes and guess how many customer requests we have had so far to add it?  I’ll give you a clue – it’s less than 1.

Anyway – apart from removing the odd bit of unsavoury language from a frustrated late night check-in, today I found a handy use for updating the comments after the fact.

In TFS 2008 SP1, Microsoft introduced a new feature in the server – to allow branches to be created and committed in a single operation.  This is exposed in the command line using the tf branch /checkin option or through the API using the undocumented VersionControlServer.CreateBranch method.  Creating a branch in this way is very fast because it bypasses the whole requirement to have a workspace created, working folders mapped, a branch to be pended and then the branch finally checked in.  It also uses significantly less server resources to perform which is why the feature got added in the first place.  Microsoft have some very large branches that they manage in TFS :-)

The problem with the current version of the CreateBranch method is that it doesn’t add a comment to the changeset during the branch operation.  But you can, as we now know, add a comment after the fact.  Below is a code snippet to demonstrate this:

public void CreateBranchWithComment(

    string serverUrl,

    string sourcePath,

    string targetPath,

    string comment)

{

    TeamFoundationServer tfs = new TeamFoundationServer(serverUrl);

    VersionControlServer vcServer =

        (VersionControlServer)tfs.GetService(typeof(VersionControlServer));

 

    int changesetId = vcServer.CreateBranch(

        sourcePath,

        targetPath,

        VersionSpec.Latest);

 

    Changeset changeset = vcServer.GetChangeset(changesetId);

    changeset.Comment = comment;

    changeset.Update();

}

Hope that helps somebody.  In TFS 2010 there is an additional overload of the CreateBranch method that allows you to optionally specify many things about the changeset created including a command and check-in notes so this workaround isn’t  necessary there. 

Remember, use your new found changeset comment altering powers for good rather than for pranking your colleagues.

I recently stumbled across a handy Team Foundation Build screensaver created by Jim Liddell and wanted to share it as it seems very good.  For my team build talks I created a Team Build Wallboard as a code sample, however Jim has created his own as a WPF based screensaver and it looks very nice.

A few features that I particularly liked:

• Deployed as a screen saver (.scr) with full configuration options via the screen saver properties
• Ability to display multiple builds from multiple team projects
• Nice, clean WPF based vector graphics
• Multi-monitor support

The code is also pretty clean, and reminds a WPF novice like me how different a true WPF based programming model can be from WinForms.  The only issue I had with it is that I had to download the source code and recompile as x86 only against the TFS2008 API’s to get it to run on my main dev machine which is a Vista x64 machine with VSTS2010 Beta 1 installed.

Anyway, the code is up on CodePlex under the permissive MS-PL license, so I would encourage you to give it a look and give Jim your feedback or even contribute back features that you would like to add. 

Notice in the picture above that Jim has a Build Bunny sat next to his Build Monitor as well - great to see them breeding like, well – you know…

A guiding principle with Team Foundation Server is that all the flexibility of configuration and all the control should not get in the way of getting work done.  For example, if you try to do a check-in that fails a defined check-in policy, you get the following warning.

The key thing about check-in policies is that you can always override them.  Some check-in policies (such as the Build policy) actually rely on this behaviour.  However, this fact can irk some software configuration managers when they first figure this out.  They’ve defined a check-in policy for a good reason, and gosh darned it they do not want their developers to be able to check-in unless they meet the check-in policy or they better have a really good reason.

Now, don’t get me started on how check-in policies can be abused in TFS.  Like all shiny new toys, sometimes people can go crazy with them and have check-in policies to enforce things (such as code coverage) that in my opinion would be best covered by an automated build system.  But that rant is off limits for today.  Let’s take a check-in policy that I wouldn’t have a problem with, the check for work item policy.  This policy ensures that you developer has captured which work item the check-in is related to.  The key point about this check-in policy is that if you do not capture that information now then it is hard to remember exactly which work item that should be later on. 

When introducing this new check-in policy to a team, you want to make sure that everyone understand the value in associating work item to check-ins.  Being able to explain this to a large team also makes you question the value yourself which is an important self check before switching it on.  Remember All check-in policies cost money.  Each check-in policy you enable will slow down the check-in process just a fraction.  As you want people to be checking in regularly this fraction is amplified.  Taking a rough figure of each check-in policy takes 5 seconds to ensure you have correctly met, roughly translates to 5 cents per check-in for developer time in a US company,  Say you have on average 6 check-ins per day (a figure that you are always trying to raise).  Therefore, this quick back of an envelop calculation puts the annual cost of a check-in policy to be around $70 per developer per year.

Not a huge amount, considering how much free soda a developer can drink in a year – but still not beer change either.  The key point is not so much cost, but that the cost is per check-in.  People always try to take the path of least resistance, therefore the more you penalise the check-in process by slowing it down the less often people will check-in – which is exactly the opposite behaviour that you want to encourage.

Anyway, once you have convinced everyone including yourself of the value of a check-in policy, you now want to encourage people adhere to it.  The problem of course is that check-in policies can be overriden by checking a box and typing in a single letter as the comment.  Overriding check-in policies is something that you want people to think carefully about, and in my experience the best way of making people think about something in the development process is peer pressure.

Configuring Email Alerts for Check-in Policy Overrides

For people to not override a check-in policy without thinking about it, there has to be some penalty involved in overriding the policy.  Often this is simply the fact that the policy warning box will pop up.  It is usually easier to find the valid work item than it is to go through the check-in policy override dialog.  That said, you can easily configure TFS to send an email to an individual – or more usefully in this scenario – a distribution list every time someone overrides a check-in policy.  This has two effects.  First, it makes them think if they have a good reason for overriding the policy – their managers and peers will get an email if they override, so this makes you pause for thought straight away.  Secondly, because the comment provided in the check-in policy override is in the email sent by TFS it encourages people to properly document the reason for the policy override in the comment box rather than just typing some random characters.

The easiest way to create a check-in policy override email is to install the Team Foundation Server 2008 Power Tools.  This includes the very useful alerts editor into your Team Explorer.  Double clicking the Alerts node in Team Explorer will bring up the alerts editor, where you can press “New” to create a new alert.

There are a number of default alerts provided with the tool, and the one that we want is under the Check-in Alerts section, “Check-In to a specific folder with a policy overridden”.

In the alert, you then provide the email address that you want it sent to.

If anyone now overrides the check-in policy, and email will be sent to the address provided in your alert along with the reason they provided for overriding the policy.  It’s then up to the organization to ensure that these stay rare events, that people not providing a good reason are suitably ashamed and that everyone just doesn’t set up an email filter to send those messages to the trash.

As with all actions, there are consequences which you have to think through.  For example, by switching on the work item association policy and enabling policy override emails are you now making it so that people will randomly associate a check-in with any work item?  It’s because of constant issues like this that you have to make sure everyone understands why the check-in policies are in place in the first place and buys into the procedure that you would want them to follow.

Last week at TechEd 2009 North America, I had the pleasure of sitting down with Brian Keller to discuss Teamprise past, present and future. If you have Silverlight installed you can watch the interview or you can download the video from the TechEd site.

If bunnies are just a little bit too cute and fluffy for you, then you might be interested in a little side project that reader Terry Humphries just got in touch with me about.  You see Terry had no love for robotic rabbits in the build process – but an electric guitar was something that he and the other developers in his team would pay attention to. So he hooked up a vintage 1990’s Warlock Electric guitar made by B.C.Rich to TFS and let that rock their world.  I thought this was a cool project so asked permission to share his email with you all. If you want to get in touch with Terry, drop me a line and I’ll send your details on to him.

From: Terry Humphries

My name is Terry Humphries and I work for EnGraph Software. I’ve been a developer for over 25 years the last three months at EnGraph. I came here to join a development team that was scaling up from a couple of developers to over 14 folks. Part of my job has been and continues to be leading EnGraph’s push into using Team System. I spend part of my time wearing a developer hat and part wearing the TFS admin, Build Sensei hat.

Having always been a strong believer in nightly builds and making sure everyone is aware of the status of the build, I’m always looking for ways to get the other developers invested in the status of the build.

Having seen Brain aka the Build Bunny and the Lava Lamp build indicator I decided it was time to create something unique for EnGraph to use.

I almost used a full size traffic light, but since all of the pcs here are named after guitar manufacturers, a Build Guitar seemed the way to go, and the search was on. It took me about three week to locate the used Warlock I used as the basis of the project. I didn’t want a run of the mill guitar, it need to be electric and it needed to have a unique look. When I got the Warlock it’s better years were behind it, the body was in bad shape. I had to end up stripping it, filling in a few dings and refinishing it with a purple undercoat and a bronze metallic pearlized overcoat.

I looked at several options for the switching mechanism for the LEDS. Basically, I wanted something that would provide the low dc power needed to drive the LEDS and a programmable interface for switching them on/off. I considered Ethernet based relays, Bluetooth based relays, Ethernet to parallel port converters, and USB controlled relays. Mostly because the other options were much more costly I settled on the USB controlled relay. I decided to mount this control circuit in its own box and use standard Ethernet cabling to get the power to the guitar from the relay. With this option the only things I had to mount in the guitar were the LEDs, the Ethernet jack, and wire connecting them.

Once I obtained everything I need I started build the controller. Wanting it to also be somewhat different I decided to mount the relay circuit old 3.5 diskette plastic case that was designed to hold 10 diskettes. After mounting the circuit board I added the ethernet jack and connected the power supply. Cut a few hole for the cables and bam the Build Guitar Controller was born.

Next, guitar time. I decided the best place to mount the LEDs was in one of the pickup coil frames, you see a Warlock comes with 2 Humbucker pickup coils each mounted in its own frame. I fashioned a piece of black plastic to fit the frame and drilled three holes for the LEDS. Then I wired the LEDS to the Ethernet jack I had placed in the jackplate.

Then I hooked everything up loaded the Phidgets drivers and using they’re control panel applet tested the wiring and after a few minutes I had everything working as planned.

The folks at Phidgets provide 2 way to interface with their devices, either directly or via a webservice, I used both. I couldn’t find a TFS event that fires when a build starts so I created a custom task that turned on the correct relay and hooked it into our build scripts via the BeforeEndToEndIteration target and then used Howard van Rooijen TFS Event Framework to react to the BuildCompletionEndpoint to set the red and green leds.

The basic code for manipulating the relays is only 9 lines:

InterfaceKit RelayPhidget = new InterfaceKit();

RelayPhidget.open("gibson", 5001);

System.Threading.Thread.Sleep(1000); //wait for the server to connect

RelayPhidget.outputs[0] = false;     //Set build start off

RelayPhidget.outputs[1] = true;      //Set build success on

RelayPhidget.outputs[2] = false;     //Set the other off

RelayPhidget.outputs[3] = false;

RelayPhidget.close();

RelayPhidget = null;

I’m not sure what else I can tell you about it other that it’s a big hit with the other developers. As for more about EnGraph you can visit our web site at www.engraph.com

Hardware:

• Warlock Electric guitar made by B.C.Rich vintage 1990s
• 10MM diffused LEDS in Blue, green and red
• Phidget Interface Kit 0/0/4 available here
• 5VDC 350milliamp wallwort power supply
• Various bit of wire, tape glue paint, etc.

Software:

• Team Foundation Server Notification Event project template from Howard van Rooijen
• VS2008
• Phidgets Driver

Thanks for sharing this with me Terry, and for allowing me to post your email.  For anyone interested, I’ll be talking more about integrating with Team Foundation Build API’s during my session at Tech·Ed North America 2009 next week.

DTL307 Brian the Build Bunny: Extending Team Foundation Server Build

Fri 5/15 | 9:00 AM-10:15 AM | Room 404

This session digs deep into customization of the Microsoft Visual Studio Team System Team Foundation Server Build system. Learn about the .NET API for Team Foundation Build and how to use it to create your own build status display or even have your team chastised about build failures by a robotic rabbit.

For a while now, we’ve been helping our Java customers by providing the Teamprise Build Extensions to allow people to easily build Ant based projects using Team Foundation Build and publish JUnit test results into TFS for inclusion in the reports etc.  With the release of Teamprise 3.2 we also released a new version of the Teamprise Build Extensions which enables Maven based builds to be performed under Team Foundation Build with the same ease.  We’ve been using this with a few different customers this year and it has proven to be very successful so I wanted to spread the word a little.

The easiest way to build a Maven project from Team Foundation Server is to install the Teamprise Build Extensions on your build server using the MSI installer provided on the download site (http://www.teamprise.com/products/build/).  You must also have a Java JDK and a copy of Maven 2 installed on the build server.  See the User’s Guide for full details.

You can then use a copy of Teamprise Explorer or the Teamprise Plug-in for Eclipse to create the build definition. 

Once you have given the build definition a name and specified what should be included in the build using the usual options, go to the Project File section. 

Just as in Visual Studio you can change the folder that you want the build configuration to be stored (1) but when you press the Create button (2) things differ a bit from  the Visual Studio interface.

As you can see, you are prompted as to what type of build you would like to create. When connected to a TFS 2008 server you will be offered two options, Ant and Maven.  In our case we are going to select Maven and then we get to pick the master POM file for our Maven 2 build

The wizard will then create the TFSBuild.proj file necessary to run the Maven 2 project and check it into the build configuration folder specified previously.  You can then define you trigger and build agent just as you would normally and you should be good to go.

As well as creating the build definition, the Teamprise client simply creates a TFSBuild.proj file in the following format which you could easily create yourself if you wanted to create the build from Visual Studio or something.

<?xml version="1.0" encoding="utf-8"?>

<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

 

  <!-- Do not edit this -->

  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />

  <Import Project="$(MSBuildExtensionsPath)\Teamprise\v2\Teamprise.Build.Maven2.targets" />

 

  <ProjectExtensions>

    <ProjectFileVersion>2</ProjectFileVersion>

    <Description></Description>

    <BuildMachine>buildserver.mycompany.com</BuildMachine>

  </ProjectExtensions>

 

  <PropertyGroup>

    <TeamProject>Billing</TeamProject>

    <BuildDirectoryPath>UNKNOWN</BuildDirectoryPath>

    <DropLocation>\\UNKNOWN\drops</DropLocation>

    <SkipWorkItemCreation>false</SkipWorkItemCreation>

    <WorkItemType>Bug</WorkItemType>

    <WorkItemFieldValues>

      System.Reason=Build Failure;System.Description=Start the build using Team Build

    </WorkItemFieldValues>

    <WorkItemTitle>Build failure in build:</WorkItemTitle>

    <DescriptionText>This work item created on a build failure.</DescriptionText>

    <BuildlogText>The build log file is at:</BuildlogText>

    <ErrorWarningLogText>The errors/warnings log file is at:</ErrorWarningLogText>

    <UpdateAssociatedWorkItems>true</UpdateAssociatedWorkItems>

  </PropertyGroup>

 

  <ItemGroup>

    <!--  Maven 2 Call Configuration. 

          The POM file called should be included in the workspace of the build definition.

    -->

    <MavenPomFile Include="$/Billing/Main/billing-service/pom.xml">

      <Goals>install</Goals>

      <Properties>

         BinariesRoot=$(BinariesRoot);BuildDefinitionName=$(BuildDefinitionName);

         BuildDefinitionUri=$(BuildDefinitionUri);BuildDirectory=$(BuildDirectory);

         BuildNumber=$(BuildNumber);DropLocation=$(DropLocation);LogLocation=$(LogLocation);

         SourceGetVersion=$(SourceGetVersion);TestResultsRoot=$(TestResultsRoot);

         TeamProject=$(TeamProject);WorkspaceName=$(WorkspaceName);

         WorkspaceOwner=$(WorkspaceOwner)

      </Properties>

    </MavenPomFile>

  </ItemGroup>

 

</Project>

The Import statement at the top is calling the Teamprise.Build.Maven2.targets file. This safely inserts the call to Maven 2 into the Team Foundation Build process. It uses the MavenPomFile item group to specify the server path of the POM file to build – this is converted into a local path as part of the build process.

The Maven 2 integration will listen for surefire steps as part of the build process and automatically include those files in the list of JUnit results to publish to TFS. It will also automatically copy any files in the Maven 2 targets directory over to the drop location for build archival purposes.

The Teamprise Build Extensions are provided free of charge, and the source code is available under the permissive open source MS-PL license if you want to take a look in more detail at what they do and how they do it.

Internally, we also have a Maven SCM Provider for TFS coded up and we are about to submit this to the Maven project so that people using Maven will be able to perform SCM operations easily from inside their projects (and use things like the Maven Release plug-in to perform releases).  If you would like a copy of the SCM provider in the mean time then let me know and I can send you a copy.

Looking forward to hearing what people think.  Now that we have both Maven 2 and Ant support for building Java projects in Team Foundation Server this really helps Java development be a first class citizen in the TFS world. I’m always keen to hear feedback how we can improve the situation further if you have any suggestions then let me know.