Andrew Lynes' WebLog : TFS

Installing the TFS Process Template Editor

anlynes — Mon, 28 May 2007 02:37:00 GMT

After an extended absence, I returned to ~~hacking~~ customising TFS Process Templates today. Last time I dabbled in this space, the Process Template Editor was a standalone application. It's now part of the excellent Team Foundation Power Tool. One problem... I installed the Power Tool and couldn't find the Editor anywhere. After a quick look around, I learned I needed to install Domain-Specific Language Tools for Visual Studio 2005 Redistributable Components. No problemo... but still no Editor. I then repaired the Power Tool... but still no Editor. It was only after an uninstall/reinstall cycle of the Power Tool did the Editor appear on the Team menu of Visual Studio.

The moral of the story... RTFM and install the DSL Tools before the Power Tool.

First Canberra VSTS User Group Meeting

anlynes — Wed, 24 Jan 2007 02:52:00 GMT

We had a great turnout this morning. Thanks to everyone that attended. If you haven't had enough of me, attached is my slide deck (as an mht file) on "Migrating VS2003 Users to TFS Source Control". For those that couldn't make it, this outlines some of the experiences I had on a recent migration project. I've blogged about the content in the past, but now you can take it home.

Renaming/Nuking TFS Fields

anlynes — Wed, 24 Jan 2007 02:40:00 GMT

Last week I found myself creating a custom work item and needed to add a few new fields to TFS. That wasn't anything special in itself, but when I decided to change the names of my new fields (I'm blonde after all), things became more interesting. It turns out that TFS can only have one field for a specific friendly name. That sounds obvious, but when we also provide a "ReferenceName" that has a distinct namespace feel about it, I thought I could get away with it. Wrong!

Fortunately there's a neat tool that ships with TFS to rename fields (and other stuff). Check out witfields.exe. You won't use it all that often, but it's good to know it's there.

Canberra VSTS User Group

anlynes — Wed, 13 Dec 2006 06:59:00 GMT

Just in case you missed it... Check out Nils' blog.

It looks like I'm going to be one of the first ~~bunnies~~ to present. Hmmmm, where to start? I think Grant and I should be able to come up with something from our recent migration gig. We're 2.5 months on from going live now, so we've got a pretty good idea what worked and what didn't.

So do you need a development environment for TFS?

anlynes — Fri, 01 Dec 2006 02:00:00 GMT

One of the great things about TFS is that you can place the "crown jewels" of your development activities in a single safe location. The consequence for me is that I'm somewhat paranoid about using a production TFS installation for TFS R&D activities. For example, should I install a process template provided by a third party on my production server simply to have a look at it? IMO, absolutely not!

It's not to say you can't use your production TFS installation for some R&D work. Where I get sensitive is where this work requires changes that can't be confined to a single team project. At my current site, planning for replacing a CruiseControl/NANT build solution with Team Build is being undertaken using a team project on the production TFS installation. It's nicely contained, and TFS is being used as intended... to support development. However, having looked at one or two commercial process template offerings which require me to run MSIs on the TFS servers, there is no way I would put these anywhere near production (Why do software houses still get MSIs wrong?).

Where does that leave us? In short, you will probably need somewhere to try new TFS "things" independently of production. Virtual machines are the obvious solution, however if you plan migrate a lot of source from VSS into TFS, I would recommend that you get yourself some physical hardware. This allows you to iron out migration issues in a semi-realistic fashion before you involve the production installation (see some of my previous posts on the problems of repeating a migration over and over on the same TFS installation). Regardless of the choice, you will need to consider how you're going the license the development TFS installation (development is production for TFS after all). For low usage (which should normally be the case), the Workgroup Edition of TFS may fit the bill. I'm actually a fan of both approaches. I use VMs to "play" and a physical development installation to implement the next round of TFS changes. If Humpty-Dumpty has a big fall, at least he won't take out all my (or my customer's) source and developer productivity with him.

So how do you find time to manage TFS?

anlynes — Mon, 16 Oct 2006 15:51:00 GMT

TFS is a large product. Not a day goes by for me without discovering something new. With this size and complexity comes the potential for a significant administrative burden. Create a team project here, assign some permissions there, and the poor TFS administrator will be run off their feet. Sound familiar? IMO, this type of administrative model, while seemingly attractive, goes against the spirit of TFS. It isn't called Team Foundation Server for nothing

Developers have earned a reputation for being "cowboys" and in many cases, not without reason. This alone causes organisations to control access by developers to resources of any type. TFS is often no exception. However, I believe that TFS is a development tool that is best left up to the development teams to administer. But before you pack your bags to join me on the commune, this does not mean that everyone is made a TFS Administrator. The key is a well thought-out process of delegation. That is, rather than lock everything down so tight that the TFS administrator has to do everything, figure out what you can safely outsource to the users.

Safely outsource? Is that possible? Here are a few thoughts:

Remember that you can't permanently delete items from source control. This means that any "mistakes" can generally be undone. You may therefore get away with granting more access to source control by default than you may have initially thought.
Let the owner of a team project look after it. Sure, Project Administrators can delete the project, but if you're truly worried about that (given that you have to go out of your way to actually torch a team project), you probably have the wrong people on the payroll!
Do you really need to be the one that creates all the areas for a team project? One option is to allow a group of users to create sub-areas beneath a node of your choosing. If it gets out of hand, all your reports can still work against the node you initially created.
Don't fall into the trap of managing TFS security by assigning rights to individuals. Always use groups of some description. Where this isn't feasible, outsource it.
Don't try to keep secrets. Granting read-only access to everything by everyone by default can save a lot of administrative time. Besides, not hiding anything is great for communication!

Now for the words of warning... Keep your TFS Administrators (and Project Administrators for that matter) down to as few people as possible. These users can really wreak havoc (I guess I'm about to be booted off the commune). Finally, keep your IT Pros (and DBAs) away from TFS. Trust me, they can't just "tweak" it to make it better. Don't get me wrong, IT Pros are absolutely essential to the delivery of good software. However, we sometimes have different opinions on how to achieve it.

The Road to TFS - Experience from the Field (Part 3)

anlynes — Tue, 10 Oct 2006 13:59:00 GMT

So one week on, how did it pan out? In short, not bad... not bad at all.

We had about 100 users come on board on Day 1. We saw a reasonable amount of load on the TFS servers for about 4 hours, as users populated their workspaces. After that (and subsequent days), things tapered off quite nicely. We regularly see 50% spikes on the DT CPU, but these generally don't last more than a second or two. The AT seems to basically have its feet on the table.

That said, we did run into one hitch with the MSSCCI provider. We found that creating a new branch doesn't cause the provider to prompt for binding information. It simply sticks with the original, which is definitely not what we want. There is a workaround (namely to rip the binding info out of the branched project files etc), but it ain't pretty. I'm sure this will be sorted in a future release.

Looking back, we had a comparatively smooth ride, even though we targetted VS2003 users. For anyone considering such an upgrade, I'd recommend you go for it. Just remember to plan and practice everything.

The Road to TFS - Experience from the Field (Part 2)

anlynes — Wed, 04 Oct 2006 12:35:00 GMT

This is a follow-up to my last post where I'll talk about the highlights and lowlights of our TFS deployment project.

So how were the requirements met?

Yes, we used VSSConverter. It turns out that that it's quite a resilient tool. We managed to import over 162,000 files with their respective histories, even with a few server issues (more on this later). The whole process was completed in under 12 hours.
VS2003 integration was delivered via the MSSCCI Provider for TFS.
We actually continued using CruiseControl and NAnt for the .NET 1.1 build server. We did investigate moving to Team Build, but we decided our efforts could be better spent elsewhere. This did however require us to rewrite the version control integration code used by the build solution.
In order to handle the security requirements, we created a customised Process Template for the VSS database in question and generated both TFS groups and TFS areas for each resource being secured. By default, developers were granted read-only access to Version Control and only picked up read/write access to a resource through membership of the resource-specific group. We did some creative stuff with XSLTs to generate the Process Template from a VSS directory structure. Group membership was seeded from another database and is managed on an on-going basis via a simple website (that was part of the original central build solution).

And what didn't work as expected? Well, there were a few bumps along the way...

Repeated trial migrations (of the same VSS database) got slower and slower. With help from PSS, it appears that reapplying the same label over and over causes inefficiencies. We had a lot of labels (added by the central build solution), so this hurt us bad! Fortunately we were able to torch our TFS database and move on. The moral of the story is get yourself a development TFS server and be prepared to restore it to a clean state on a regular basis.
We encountered out of memory issues on the Application Tier. This seems to have been related to the first issue, but we still got a couple on a clean TFS database. In the end, VSSConverter coped with this and finished its work successfully.
The MSSCCI Provider prompted for a username and password at first use, which was a potential show-stopper because we almost exclusively use SmartCards for workstation access. This was traced to our TFS boxes being in a different forest to the clients and could be avoided through some client-side config.

So how did it pan out? You'll need to read my next post to find out.

The Road to TFS - Experience from the Field (Part 1)

anlynes — Sat, 30 Sep 2006 11:33:00 GMT

In this post, I'll outline the TFS deployment project I've been working on over the last 2 months (as part of a dedicated team). Future posts will cover some of the bumps we've run into along the way.

Here's the story... The source for one of my customer's major applications lives in a single SourceSafe database that's grown to about 2.5GB. There are over 100 users of this database and a significant portion of them rely on it for most of their day-to-day work. There have been instances where it has become corrupted resulting in an outage and some nervous moments as it was restored from backup. To spice things up, some of the developers are located 400km away in Sydney.

Given that TFS has a fairly well documented migration path from VSS, maybe this is nothing special. We did however have to deal with a few complications:

VS2003 is still being used for all development and that wasn't about to change.
A central build server based on CruiseControl and NAnt is being used and was intimately linked to VSS.
The security requirements are non-trivial and needed to be successfully mapped to TFS.

If any of this sounds familiar, you might be interested in my next post. There I'll talk about our approach to getting TFS to deliver on these requirements. We're actually going live this weekend, so by the end of the week, I'll also be able to comment whether we were successful.

Refocusing “Remaining Work” on Your TFS Project Portal (Part 2)

anlynes — Sun, 27 Aug 2006 09:38:00 GMT

In my last post, I showed how to construct a URL to get the TFS “Remaining Work” report to target a specific project iteration. Now, let’s have a shot at using this on a project portal.

The good news is that you don’t need anything special for this. As a Site Administrator, open up the project portal in IE and navigate as follows:

Select “Site Settings”
Select “Customize home page”
Just under the search box in the top right hand side of the page, select “Modify Shared Page”.
In the drop-down, find “Modify Shared Web Parts” and select “Remaining Work”.

With a bit of luck, you should now see a panel on the right hand side of the page with a “Link” value of: _layouts/tfsredirect.aspx?IsReport=1&ReportName=Remaining+Work

To report on Iteration 0 of my project, I need a URL of:

http://localhost/ReportServer/Pages/ReportViewer.aspx?%2fTrial%2fRemaining+Work&rc%3atoolbar=false&rs%3aCommand=Render&IterationParam=[Iteration].[Parent_ID].%26[19]

For our purposes, we can ditch the protocol and server name from this. This leaves us with:

/ReportServer/Pages/ReportViewer.aspx?%2fTrial%2fRemaining+Work&rc%3atoolbar=false&rs%3aCommand=Render&IterationParam=[Iteration].[Parent_ID].%26[19]

All we need to do is copy this into the “Link” field and “OK” the change. If all has gone well, we should be ready to rock and roll. Just in case you can't tell the difference between the graph below and the one above, I now have less work to do. Yay.

Refocusing “Remaining Work” on Your TFS Project Portal (Part 1)

anlynes — Thu, 24 Aug 2006 15:35:00 GMT

One of the neat things about the “default” project portal is the “Remaining Work” graph. At a glance it can give you an idea on how things are going with your project. However, it can also be misleading. On my current project, we’ve identified quite a few features/tasks that we want to complete in a future iteration. Unfortunately the “graph” shows that we’re drowning. To the guys paying the bills, that’s a bit of a worry.

The real issue is that the graph includes tasks for all iterations. Obviously the solution is to have it only display data for the current iteration. But how can this be done?

The first thing you need to do is figure out what parameters need to be passed to Reporting Services. As it turns out, that’s easier said than done. The “Remaining Work” report is driven from data in Analysis Services. The Iteration parameter is called “IterationParam” and expects values read from the corresponding dimension in the OLAP database. Cutting to the chase, you can’t just provide text such as “Iteration 1” as a value for this parameter. To illustrate, here a URL to display the remaining work for Iterations 0 and 1 of my project:

http://localhost/ReportServer/Pages/ReportViewer.aspx?%2fTrial%2fRemaining+Work&rc%3atoolbar=false&rs%3aCommand=Render&IterationParam=[Iteration].[Parent_ID].%26[19]&IterationParam=[Iteration].[Parent_ID].%26[20]

Ugly isn’t it? Focus on the first IterationParam value. After URL decoding, this equates to IterationParam=[Iteration].[Parent_ID].&[19]. This may make sense to those that have worked with Analysis Services before. In short, it is identifying the member of the Iteration dimension that has a key of 19. In my case, this corresponds to “Iteration 0”. In your case, it could be anything.

The easiest way I’ve found of determining the key to use is to look up the relevant __ID from the TfsWarehouse.dbo.Iteration table in the TFS data tier. All you need to do is find the Iteration Path you’re interested in and read the corresponding key from the __ID field. Armed with this knowledge, you can construct a report query like the one above. In case you haven’t noticed, you can nominate multiple iterations to report on by providing several IterationParam parameters to Reporting Services.

In my next post, I’ll link this into the Project Portal.

More TFS and WSS

anlynes — Tue, 15 Aug 2006 15:13:00 GMT

I’ve talked previously about regionalising the SharePoint templates that go along with TFS. Clearly it is possible to use the same technique to make changes to other properties of the templates. However, if you’re not familiar with WSS, it may not be so clear how to customise the home page of a Team Project portal. For my current TFS rollout, we needed to ditch the MSF Agile graphic, process guidance and some of the reports with links on the home page. We could have done nothing, but then we’d have several dead links on the home page… not a great first impression to those new to TFS.

The key is to get hold of a copy of FrontPage 2003 (licensed of course). FrontPage is the “native” client for SharePoint and is able to open an entire site and support the editing of content. As discussed previously, I would recommend that you “hydrate” the TFS SharePoint template to be customised into a throw-away SharePoint site. Using FrontPage 2003, you can then connect to this site and customise the default.aspx page. When you’re happy, simply save the site as a global template and you’re good to go.

When editing default.aspx, the FrontPage designer looks something like the following:

As an example, I quickly doctored the MSF Agile template along the lines I mentioned above:

One thing I have noticed is that the “Reports” link bar can become corrupted of you remove any of the “Documents” links. Unfortunately you may not see this until you create a new site based on your customised template. The solution to this is to simply delete and recreate the “Reports” link bar using the FrontPage designer and save the template once again.

Fun with TFS and SQL Server SP1

anlynes — Tue, 08 Aug 2006 15:25:00 GMT

After successfully conducting a pilot deployment of TFS to a single-server running Windows Server 2003 SP1 and SQL Server 2005 RTM, the time came this week to deploy to production. To make things interesting, we decided to roll-out a dual-server configuration running Windows Server 2003 R2 and SQL Server 2005 SP1.

The good news is that it worked... eventually. While Win2k3 R2 posed no challenges, SQL Server SP1 turned out to be somewhat "precious". The latest TFS installation guide recommends that SP1 be used in place of the Analysis Services hotfix. It also recommends that you read the preparation steps and installation instructions for the service pack. That's good advice, but it probably understates the need to become familiar with the SP installation process. We encountered a few issues:

The service pack throws up a couple of question/warning/information messages such as "Pending Reboot Files Found". These are benign and you can answer "Yes" to proceed.
There are other messages about various files being "in use". This was true, but they were being used by components of SQL Server itself. While it would have been nice for the SP to have sorted this out automatically, we simply shut down the offending services and continued. We probably didn't even need to do this.
After "successfully" installing the SP and rebooting, "Integration Services" failed to start. It turns out that this happened to us because our SQL Server was buried deep within an EDC and didn't have Internet access: http://support.microsoft.com/kb/918644. The solution... install the "Cumulative hotfix package (build 2153) for SQL Server 2005".

If you're following this, I'd recommend you make a cup of coffee at this point. The hotfixes don't take too long to install, but you've still got a lot of installing to do (of TFS etc). Before leaving the topic of hotfixes, expect to see similar question/warning/information messages that you saw when installing the SP. As before, these are benign.

If you're like me and go trawling through server logs looking for things that are broken, you might stumble across the following message in the SQL Agent log:

[298] SQLServer Error: 2812, Could not find stored procedure 'msdb.dbo.xp_sqlagent_notify'. [SQLSTATE 42000] (DisableAgentXPs)

This is a side-effect of SP1 and is benign.

Despite all of this, the rest of the TFS deployment went smoothly. Those of you that used the Betas would know that the TFS installation process has come a long way. Based on this experience, it may have actually overtaken SQL Server for ease of installation (well at least SP1).

The take-away from this experience... make sure you trial your deployment script to the letter, so you know what to expect when you deploy TFS for real. If I had followed my own advice, I would have saved a few hours diagnosing "possible" SQL Server issues.

And one more thing...

anlynes — Tue, 01 Aug 2006 14:04:00 GMT

If anyone's wondering how to stop the MSSCCI provider for TFS from prompting for a username and password in some cases, take a look at the following:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=594542&SiteID=1

Thanks Grant for the answer.

Using MS Project with TFS Redux

anlynes — Tue, 01 Aug 2006 12:53:00 GMT

In a previous post I talked about an approach for using MS Project with TFS. After applying this to a real project and receiving feedback from the team, I’ve come up with a refined process. The most significant change is that roll-up tasks should not be published to TFS. This avoids confusion among the team and stops MS Project from over-allocating work when levelling resources.

All data entry steps outlined below should be performed in the “Team System Task Sheet” in MS Project.

Create “Outline Level 1” tasks to identify the project iterations. Set the TFS “Publish and Refresh” for these to “No”. This simply means that work items will not be created for these tasks.
Set the “Iteration Path” to an appropriate value for these and all subsequent tasks.
Create “Outline Level 2” tasks to identify the “big-ticket” tasks. Set the TFS “Publish and Refresh” for these to “No” as well.
The first sub-task for each “big-ticket” task should be to create the work breakdown structure for the task. These should be assigned to lead developers.
At this point, the tasks can be published to TFS so the team can get cracking. Even though the lead developers may own the “create WBS” tasks, the whole team should work on these.
Any resulting work items can be imported back into MS Project and collected under the original “big-ticket” task. This will allow delivery dates to be estimated and resource availability to be assessed (assuming the team also estimated the work required for each work item). Note that the collection of new tasks under the appropriate “big-ticket” task is a manual process. You might need to get your team to add some form of identifying text to the new work items so you’ll know where to put them.

You should end up with a task sheet that looks like the following: