Loïc Baumann's Blog

Installation:

• A lot easier and faster than before. You can now install and setup the whole stuff in few minutes.
• An administration application let you setup the WICreator for your TFS Server, and for each Team Project you want.

User experience improved:

• The last used Team Project is restored when launching the WICreator application.
• There’s now a Most Recent Used (the yellow star icon) Work Item menu item.
• The user can create several Work Items at once, based on predefined templates.
• Area Path and Iteration can now be spread among children.
• The hierarchy fields are automatically added to a Team Project’s Work Item Type definitions when they’re not present.

Integration using Work Item:

• The integration process can be driven by Work Item (you have to follow the 1 changeset / 1 Work Item associated rule strictly). Integration features will be available to member of a given TFS Role.
• The Branch Comparison feature display for selected branches (scoped in time) what Work Items are implemented or not.
• The Make New Release feature enables you to merge your work based on Work Items. A Work Item query lists all the Work Items concerned by the integration (typically filtered by Iteration) and is filtered by the ones that are present in the source branch and not in the destination one. The user can choose the Work Items to merge, then their corresponding changesets. The Release process then merges all the changesets, and keep the association with the corresponding Work Item.

Misc:

• The hierarchy of the Work Items on a given Team Project can now be checked for integrity (only users having the Integration role can use it) and fixed if there’re problems.
• Many little bugs fixed.

This is will be short. I wanted to say few things:

1. Good job the TFS Team for the TFS 2008 Release! Especially for the GetMergeCandidates API improvement! I blogged about that in the past: in TFS 2005 it was bugged, and slow. And now I can say: "yey, it's fast and it's working!"
   Now it's bug free: I could remove the code I've made in WICreator for the "Merge by Work Items" feature.
   Before it took around 10 minutes for one API call for two branches with lots of changesets, now it's taking only 20 seconds! The integration people loved the TFS 2008 upgrade, I can tell you!
2. As I said in a recent post on the WICreator Codeplex's project, I'm starting again working on WICreator, the "Merge by Work Items" feature is pretty stable and usable now (we use it in production for at least 4 months; we did around 30 releases with it). So I'm going to make a new Codeplex release, containing this major feature, and small other ones.
3. I'm thinking about an "administration" part for WICreator that will do for you most of the boring tasks post setup: WITs' fields creation for hierarchy, alert registration, few configuration of the NetworkModels.xml file. I think this feature would enhance the adoption of WICreator and WINetwork.
4. I'm going to work on a "killer feature", well, more a "flashy feature", I hope it won't take too much time or I won't be able to release it. I really hope I will find time to do it, because it's going to be great!
   One hint: WICreator is going to be .Net 3.0!

That's it people, keep in touch for coming events.

Thanks to all the people who use WICreator, drop me a comment if you use it, I'm always curious! :)

The "Merge by Work Item" feature is quite harder to implement as I expected.
The main reason is the issues I encountered with the Source Control implementation in Team System.

I first wanted to rely on the GetMergeCandidates API to filter the changesets that were already merged between the two branches, only to find out several weeks later (and several forum posts and Email with MSFT) that this API is bugged, and doesn't returned all the changeset it should !
Not cool...

I tried many things to solve this issue, and I finally came with a custom code that "complete" the result of this call, apparently I have now the full list of candidates, but man, it's damn slow to compute!

Finally, when I thought everything was ok, I find out that it's completely impossible to do two consecutive merges on the same file if I don't do a check-in between them!
That's it: you can't do all your merge operations, then finally check the result in, you have to do one merge, one check-in, then loop to the next changeset to merge. I don't know if I'm the only one, but I find this awful!

We want to use the "Merge by Work Item" feature to drive the making of our software release. This cycle happens every two weeks, and we can have 20 features (Change Requests or Bugs) made of 1-3 implementation Tasks each, with at least 1-3 changesets to each task. The reasonable number of changesets to merge is around 200!

Two hundred consecutive check-ins!!! Are you kidding me? By the way, I tried, and looks like spamming merge+checkin operations to the TFS server continuously doesn't end up good!

I really hope Orcas will have several improvements on the branch/merge management, it's good to have new high level features, but having the "good old low level" ones working perfectly is still for me the priority!

Here's a little snapshot of the main form of the Merge by Work Item feature:

Using the Work Item Creator to create Work Items in a hierarchical way was the first step to reach one of the goals I set myself.
The Work Items are here to describe your project:
 - On the management side with mainly the Change Request and Bug ones.
 - On the development side with mainly the Task ones.

What about the interaction with the Source Control? Well, when we check-in code, we associate a Task Work Item with it. The Task is owned by a Change Request or a Bug, which symbolize a feature or a fix.

All the code we're checking-in is in a "Dev" branch, whatever the iteration we're targeting, when the development is done, it's checked in there.
Alongside with the Dev branch, we have one branch (created from the Dev on) per release of our software.

So what am I so interested to do? Simply to control the creation/update of a release through the use of the Work Items!
A release is done by selecting the features/fix you want it to contain through the selection of the corresponding Work Items. The Work Item Creator will analyze the changesets that belong to these features, and merge them to your target branch, ignoring the ones you don't want!

Here's a preview of the form:

A quick post to say there's a release 1.3 of the Work Item Creator on Codeplex, the sources (including the setup) are updated and in sync with this release.

I've added few features:
1) Now you can customize the Actions menu to specify the types of Work Item you want to create.
2) The icons corresponding to the Work Item types are now stored on the WebService so that you can add icons for your own custom Work Item types (see the "About & Setup" document about that).

I also fixed few bugs.

Drop me a message on Codeplex if you're using it, I'm always interested to get some feedback!

It's a start, the setup process is not as easy I'd want to, but I can assure you it worth going through it!
I'm waiting your feedback by email or directly in the discussion forum in Codeplex.

If people are willing to help the application evolving, let me know!

Concerning the Work Item Creator application, I've added interesting features:

• Siblings ordering in the hierarchy.
• Tree View filtering by Title content and by the following fields of a Work Item: State, Created By, Assigned To, Work Item Type. The possible values are dynamically built, I'm kinda proud of it! :)
• The saving process was optimized.

To release them I have to enhance things because I really do want them to be highly configurable and adaptable to your Process Template. That means I have to be able to deal with any kind of Work Item Types (as long as my three custom fields are declared), custom States, etc.

We use them in production already, and if there's a release, I want any team to be able to use them in production too. Otherwise it would be pointless...

I also want both WICreator and WINetwork to be plugable. The first in-house plugin will be the creation of Work Items from JIRA Issues in WICreator and the workflow synchronization between a Work Item and its corresponding JIRA Issue in the WINetwork.

The wish list for WICreator also includes:

• Ordered Hierarchy (almost done).
• A filter for the TreeView (Work Item Types, States, Owner).
• A "Favorites" list for the recent opened databases.
• Visual Studio Package instead of a standalone application? (your thought about that is welcomed)
• Integration with MS Project Server (in my dreams or at least in a not so near future): linking a Work Item with a MS Project Task, being able to update the task from a Work Item. No more Project Web Access for timesheet updates!

Stay tuned!

As I wrote in a previous post, I was using the Work Item's Links (to link a son with its father) and a custom field "ParentWI" to handle the Hierarchy.

The pros:

• I'm relying on existing features of Team System, it's supposed to make the enhancement tighter with the original software.
• I thought it would be easier to code it that way... Well, until I had to code it!

The cons:

• It turned out that the Links of type "Work Item" are bidirectional, and then automatically created on the opposite way when you create a new link. This is a REAL PAIN for the implementation, because you constantly have to SyncToLatest() the opposite Work Item after creating a Link. And looks like it's not always working: there are some times when I have exceptions raising because of my Work Item not up to date with the server.
  
  This issue is emphasized by the fact that you CAN'T merge Work Item: I you made changes locally and the Work Item was changed (due to the bidirectional link creation, for instance) by the time you save it, it throws you an exception...Not very handy or easy to encounter...
  
  
• There is no order between siblings, not even a chronological one. I first thought that the order will be chronological, but it turned out it has no sense at all (on a functional point of view). And my teammates yell at me "why the order changed suddently!!!"

I came to the point that I had to implement hierarchy in a different way: forget about the Links, this is just a nightmare for WI Hierarchy and I can't really see the advantages for the price I pay to use them.

The solution was not complicated to find: add two more custom fields.
"FirstChildWI", it contains the ID of the first child of the Work Item.
"NextWI", it contains the ID of the next sibling.
I don't need a "PrevWI" kind of field, parsing backward is not very useful, and I can still do it without it.

Another solution would have been to create a "ChildrenWI" custom field of type String that references all the children in a given order. But I assumed (maybe I'm wrong) that the String type has a limited size, and I wouldn't want to limit the count of children.

So here I am, three custom fields for the hierarchy, no more Links to handle, a simplified saving process, and I still kept the ability to create new Work Items in a hierarchical way WITHOUT saving them right away (which lets the user the possibility to "delete" the Work Item if needed).

The user has the ability to reorder its Work Items, life is good! :)