Partilhar via

VSTS Work Item Type Designer Preview

  • Artigo

Hi,

This is yet another long awaited “project” that I’ve been working on behind the scenes, the exponential improvement of the DSL Tools over the last year has meant I’ve had to throw away more and more code which is a great story for how compelling the DSL Tools can be, plus Team Foundation has only just shipped so the potential audience for such a tool has been pretty limited.

For those of you not in the know, The Domain Specific Languages (DSL) technology from Microsoft which is currently in Beta allows you to define a Domain language and then develop a graphical designer with next to no code. The designers are built on the same platform as the "Whitehorse" designers shipped in Visual Studio Team Architecture so you can acheive the same look and feel.

As you may or may not know, Team Foundation Server has a concept of Work Items. These Work Items can be bugs, tasks, requirements, or anything you like – they are rendered as “forms” inside Visual Studio 2005 Team Explorer or the Team Foundation Client to track, create and modify Work Items.  

Microsoft Project and Excel can also be used to manage these Work Items and the programmability interface is exposed via a .NET API and a Web Service meaning third-parties can also provide tooling.

Team System ships with the following Work Item Type definitions out-of-the-box and they will be available dependent on the Process Methodology that you select when creating your Team Project: Bug, Task, Requirement, Quality of Service Requirement, Risk and Scenario.

Quite often customers will be happy to use these Work Item Type, but more often than not you may not like the terms we use such as Iteration, Milestone, etc. and you can change the names of any of the items on these Work Item Type definitions and if you want to collect further information you can add your own fields.

In Team Foundation V1, there is no graphical tool to customise these work items so you’ll need to use your favourite XML editor (normally notepad!) to customise the work item XML. The Work Item XML document is fairly complex and has lots of intra-dependencies so you have to be sure to get the spelling of everything right for example.

Within a Work Item Type definition you essentially have a Workflow, you have a set of possible states that a Work Item Type can go through (Active, Resolved and Closed for example) along with possible State Transitions that can occur (i.e. you can go between Active->Resolve, Resolved->Closed, Closed->Active but not Active->Closed).

This type of workflow is very hard to visualize in an XML document which is where the VSTS Work Item Type designer comes in, I reference such a designer in my DSL Tools Chapter which is part of the Professional Visual Studio Team System book – it includes a screenshot of an early version of the designer.

The designer leverages DSL Tools and Visual Studio 2005, a Domain Specific Language model has been defined based on the Work Item Type Definition language and a graphical modelling tool has been overlaid on top, apart from defining the language model which is pretty straight forward the only real code I’ve had to write is to load the XML up into a serializable class and map to the domain model and vice versa which is a compelling story for the use of DSL Tools.

The current domain model is shown below:

The designer presents a graphical view of a Work Item Type definition, States are shown with connectors representing the allowed State Transitions between and Fields directly used in State Transition validation are depicted directly on the State. The Work Item Type Explorer pane shows the language model in its entirety including all of the available fields (not all fields have to be used by State Transitions).

The Toolbox on the right hand side lets you drag new States and create new State Transitions between them, new fields can be added by right clicking the Fields node in the Work Item Type Explorer. Properties of all these elements are shown in the properties pane as you’d expect.

Here is a sample designer screenshot (click for a larger image, if it looks wierd ensure IE hasn't shrunk the image by hovering over and clicking the expand icon that appears in the bottom right)

I’m currently porting a pretty-fully featured version of this designer across to the latest drops of the DSL Tools, most of the porting involves throwing a lot of code away as the more recent builds do so much, and tidying up fairly hacky bits of code that I threw together before a product team demo.

Within the Work Item Type definition there is a notion of form layout, this is used when displaying a form to the user, this is really hard to display and doesn’t lend itself to a DSL Tools Designer, hosting the Windows Forms Editor (if that’s possible) would be the better option. So layout is ignored as part of the designer but any layout already specified in the file remains (I only update the sections that can be visualized) and for new fields I insert default form layout markup which you can then change by hand.

If your interested in trying the designer out then I’ve uploaded a current release of the designer to a new GotDotNet workspace. This release works with VS2005 and it will install the DSL Tools Redist as required, you’ll also need to download the latest VS SDK (free once you've registered) as I haven’t got a Package Load key for VS2005 yet to enable it to load in a regular install of VS2005 (I have to jump through some hoops internally to get this done).

This release lets you open a Work Item Type definition that you’ve exported from Team System or created yourself and visualize it, you can add new States and Transitions, and new Fields (by right clicking Fields in the Model Explorer). 

I’ve temporarily disabled the Save feature as I’m not currently able to ensure everything in the original file is serialized out correctly (i.e. you might get a bit of data loss) – I need to ensure that all elements of Fields, States, etc. are represented in the domain model before re-enabling this.

Hopefully this gives you a taste and I’ll look to get a more complete build up in a few weeks, let me know how you get on with it!

I’ve provided a sample Work Item Type extracted from a live Team Foundation Server, if you want to extract your own from an existing Team Foundation server you can do so using the witexport.exe tool that you can find in the %PROGRAMFILES%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies folder.

witexport / <outputfilename.wit> /t <TeamFoundationServerName> /p <TeamProjectName> /n <Work Item Type Name>

Comments