Yesterdays Weather for Team Foundation Server – Part 2
February 16, 2006
In the first post in this series I outlined the rough steps that would need to be taken to implement yesterdays weather in Team Foundation Server. Before I get started on making modifications to the the work item definitions I want to cover off why I didn’t take some seemingly more simple options to implement yesterdays weather (because I know they will come up).
- Why don’t you just use the existing effort recording fields on work items like “Task”? I really wanted this sample to be free standing and not make any assumptions about what particular process template may or may not be being used – I really want to have a consistent reporting story off any work item type.
- Why don’t you just use Reporting Services to list Yesterdays Weather? Thats a good question, errr, look over there! In all seriousness though I could have done that. The benefit of this approach is that if you want to integrate it into other tools working directly against the work item store is going to give you a better data structure to work against.
Of course the other big reason that I wanted to do it was to show how to program against the TFS client API in order to get work item information out of the store – but you will have to wait for the next post until I cover that. For now – lets get started looking at the basic modifications required to support Yesterdays Weather.
Creating a Dummy Team Project
The first thing that needs to be done is to create a dummy team project to make our modifications against. You could export the process template but as you will see – doing it this way gives you access not only to the process template, but also a way to try out changes quickly.
Modifying the Process Template
Once the process template is created the next step is to go any modify the work item definition for one of the types in the team project. You could do this using good old notepad and the work item type exporter (witexport.exe) but if you want a better editing experience I would recommend downloading the Process Template Editor from the VSTS Customization Workspace.
Because Team Foundation Server is so extensible the Process Template Editor has a fairly expansive UI, so instead of documenting every single step required here I’ve recorded a short screen cast which walks you through it (sorry about the rough audio, the aircon is pretty loud). One thing that I didn’t mention in the screen cast is that you actually have to click the save button to persist the changes back into TFS – so don’t forget to do that!
Observing the Results
Once the work item has been modified and saved back into TFS the changes should become visible the next time you open Team Explorer. It is possible that the definition is being cached and if thats the case just right mouse click on the team project in the Team Explorer and select “Refresh”.
Next, run the “All Tasks” query and select one of the returned results. Notice that there is now a Yesterdays Weather tab on the screen and that it has the two fields that we defined in the Process Template Editor.
We can see the conditional rules we put in simply by changing the value of the “Publish Effort” field to true – as you can see the work item view in Visual Studio gives us some visual queues that we need to fill in the total effort field.
If you wanted to, you could then create queries that use this information. Also – using the Process Templat Editor you can choose how these fields are represented in the TFS data warehouse for reporting purposes – if you want to go down that road.
Extracting the Changes
The whole point of this excercise was to get the modifications required to the work item type definition so that we can use them as part of an installer. If I was going to productise this enhancement to TFS I would almost certainly want a reliable installer that could make the changes to the type definitions and even remove them afterwards.
We can’t just simply load in the entire definition because that might break other customisations that people have already made. I used the Process Template Editor to export the work item definition but I could have used witexport.exe as well (you can download the definition here). The first elements that we are looking for are under the fields definition:
The other elements we are interested in are the ones that define the layout:
Next Steps
Well – hopefully I’ve managed to impart some free standing knowledge there. In my next post I will look at taking the above individual XML fragments and write custom installer routines to install them into existing work item types. Stay tuned!
September 11, 2006 at 5:48 am
[...] This Could Be a Team Foundation Server Kind of Week A few weeks ago, the company I’m working with made an acquisition, thus becoming a slightly bigger, more distributed company. The acquisition started a chain of events that ultimately resulted in me pitching Team Foundation Server (TFS) to a group of executives and developers. The pitch was successful – at least I’ve been told the licenses can be purchased this week. It was an interesting (and sometimes frustrating) experience getting to this point…. ProblemsThe acquisition forced a reevaluation of existing tools and processes. With the exception of Visual Studio and SQL Server, all the tools used for product development are a hodgepodge of free software and custom-built applications. The build engine, for example, is a Windows service I wrote years ago, and before I heard of a tool called NAnt. Only two people on the planet are willing to write XML scripts for my build engine – which is one problem. A solution would be to replace my build engine with NAnt, but that only solves one of the problems. Technologies like Sharepoint only get a team so far in tracking issues, projects, bugs, and customer requirements. I experimented with a trail version of TFS and decided its features, and the tight integration with Visual Studio, would be a great boon to the team’s productivity. I was also encouraged by TFS customizations I’ve seen. For example, take a look at Mitch Denny’s “Yesterday’s Weather” post. The next step was to get a ballpark figure for licensing. I could float this figure around and see if the approach was tenable… Pricing If you ask Microsoft how to buy Team Foundation Server, they will tell you to contact an authorized reseller, or a Microsoft partner. Well, this company is a Microsoft partner. I logged into the partner website to find information, but came up empty, so I contacted the partner program directly. I would have had more success calling the psychic hotline and asking for my tarot reading, because the people I talked to in the partner program were clueless. The experience only furthered my belief that the partner program is the dimwitted step-cousin of the marketing department. Still trying to get an approximate cost for the retooling, I started searching reseller websites. I thought my head was going to explode. It turned out there were too many permutations of SKUs and licenses to make this a job I wanted to do. I read the “Software Assurance” FAQ. I looked to see what “Microsoft Open License” was. All the while, I was also trying to judge if the price I was seeing was an upgrade, or a renewal, or included an MSDN subscription, or was actually the U.S. dollar figure that resembled the price we would pay. The pain of searching through item descriptions was excruciating, so I gave up. In the end, I contacted a reseller directly (CDW, to be exact), and talked to a sales rep. The guy was fantastic, although it still took some time to figure out the exact part numbers. The DemoThe quotes I received for licensing met a favorable response, but no one else had seen TFS, so they were still a little edgy. I took the TFS Virtual PC image available to MSDN subscribers and worked up a 30-minute presentation on Team System. The execs liked the reports, work item visibility, and integration with Excel and Project. Developers liked the features, too - like how a completed work item contains a link to its changeset. There is still some concern over how much administration TFS will require. Another risk is the future of TFS, which is unclear to me. Will future versions hike up the price? Will there be backward compatibility? Despite these unknowns, I think TFS is a great choice for a relatively small company. Nothing else offers this range of features in this price range. posted on Monday, September 11, 2006 1:21 AM by scott Post a Comment :: [...]