June 2009 Archives

TFS has a many strengths.  Two of them that I particularly like talking about are it's performance over a wide area network and the strong IDE integration available for both .NET and Java developers (the latter via Teamprise of course).  Microsoft have just posted a new case study with iGate, one of the top 20 global outsourcing companies which talks about this in depth.

iGate has been assesed at CMMI Level 5, Six Sigma methodologies and is COBIT, ISO 9001 and ISO 27001 certified.  They have 8 offices in 12 countries and manage global delivery centers in Mexico, Australia, and India. Like most software development organizations, version control is critical infrastructure and they chose TFS to manage software development projects across all platforms.

When we implemented Visual Studio Team System, we noticed immediate process improvement through automation. It reduces the administrative burden and reduction in administration efforts leads to significant cost savings of 55 percent.

Chella Namasivayam M
Vice President IT & IS, iGATE.

iGate chose TFS ahead of tools such as IBM Rational ClearCase, MKS Implementer and CVS.  For more information on why and what benefits they have got from standardizing on a single platform take a look at the case study.

In TFS 2010 quite a few things have been fundamentally changed for the better, but from an end user point of view people hopefully won't notice.  Things like hierarchical work items will very quickly because just how work items should work and people will scratch their heads when they go look at a TFS 2008 or TFS 2005 server and wondered how we ever got by.

However in version control, the changes have been even more subtle from the end user point of view but are actually huge under the covers.  The biggest change by far in TFS 2010 is the move to Slot Mode version control from the current Item Mode.  Version Control PM Matt Mitrik has a excellent post entitled "Changing to Slot Mode in TFS 2010 Version Control" which I encourage you to take a look at.

"In TFS 2010, one of the more significant changes that we made to our version control platform was how we identify items.  Previously, version control operated in what we called "item mode" and in TFS 2010 it operates in "slot mode".  To better understand the motivation and impact of these changes, and what "item mode" and "slot mode" actually mean, I've decided to provide some background and detail into the changes we've made."

Matt Mitrick - Changing to Slot Mode in TFS 2010 Version Control

Basically a really fundamental concept at the heart of TFS has been completely changed - but like hierarchical work items I anticipate most people will just look at it in the future and think that's how it should always have been.  Hopefully merges will be a lot less complex but the simple things are preserved like the fact that TFS shows the history of a file from before a rename.  Note that some of these changes have not arrived yet in the Beta 1 build that is currently publicly available so we'll have to wait until Beta 2 to see exactly how the end user experience pans out. 

As well as simplifying the merge process the changes have also allowed for a big performance and scalability improvement on the server side.  Grant Holliday talks about some of the benefits that Microsoft saw internally when he discusses the "Schema Change" in the current episode of Radio TFS.

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.