This is a quick post to say I’m still alive, starting again to blog, and on a new platform.
The URL is http://loicbaumann.org (yeah, I know, egocentric, but easy to remember).
You will hear me there very soon!
Loïc
As I said there, it should be a 2.0 version as there are so many new features.
Here a Video of the installation and setup process, you’ll see it’s quite pain free now !
I’ll post more about the new features, with hopefully some videos demonstrating them.
I’m in the process of easing the installation of the Work Item Creator.
To do that, I wanted to detect in runtime if a given Team Project doesn’t have its Work Item Types (WITs) supporting hierarchy and then asking the user to add them.
It’s not very complicated to do, once you know how to do it (as always you might say).
To get the definition of a given Work Item Type and add a field, it’s not complicated:
2412 // Get the Xml Document for the given WIT
2413 XmlDocument doc = wit.Export(false);
2414 XmlElement fields = doc.SelectSingleNode(“*/WORKITEMTYPE/FIELDS”) as XmlElement;
2415
2416 // Look for each field, and add the ones that are not present
2417 XmlElement field = fields.SelectSingleNode(“FIELD[@refname=\"Cegedim.ParentWI\"]“) as XmlElement;
2418 if (field == null)
2419 {
2420 field = doc.CreateElement(“FIELD”);
2421 field.SetAttribute(“name”, “ParentWI”);
2422 field.SetAttribute(“refname”, “Cegedim.ParentWI”);
2423 field.SetAttribute(“type”, “Integer”);
2424 field.InnerXml = “<HELPTEXT>The ID of the Parent Work Item</HELPTEXT><DEFAULT from=\”value\” value=\”0\” />”;
2425 fields.AppendChild(field);
2426 }
To validate the type before importing it:
2453 WITValidateSucceed = true;
2454 prj.WorkItemTypes.ImportEventHandler += new ImportEventHandler(WorkItemType_ValidationEventHandler);
2455 WorkItemType.Validate(prj, doc.OuterXml);
2456 if (WITValidateSucceed == false)
2457 {
2458 MessageBox.Show(“Work Item Type couldn’t pass validation, something went wrong”, “Work Item Creator”, MessageBoxButtons.OK, MessageBoxIcon.Error);
2459 return false;
2460 }
The registered event will be fired if the validation failed. Why the Validate method doesn’t return a bool, I don’t know…
2473 void WorkItemType_ValidationEventHandler(object sender, ImportEventArgs e)
2474 {
2475 WITValidateSucceed = e.Severity == ImportSeverity.Error;
2476 }
Then, you’ll have to call Import from the WorkItemTypes collection to update your type:
2461 prj.WorkItemTypes.Import(doc.OuterXml);
prj being your Work Item “Project” instance.
Now there’s a small trick and if you don’t know it, you’ll be like me, wasting 2 hours trying to figuring out why your application is totally crashing when you try to modify two WITs in a row.
Importing an existing WIT will update the server side, but apparently the definition of your WITs are cached in local, and this cache is not updated by the Import method (it could have been…), so if you try to modify a second WIT, somehow the Team System Object Mode doesn’t like it!
The solution is not that hard though, after your import, you only have to call these two methods:
2401 m_WIS.RefreshCache();
2402 m_WIS.SyncToCache();
m_WIS being your instance of the Work Item Store. This way you local version is updated, and you can keep working on WIT modification!
This is will be short. I wanted to say few things:
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!
This post may be helpful for the people who are looking to get the content of a given label in a Workspace.
I looked for the code snippet on the internet unsuccessfully, to finally ask for help on the TFS Forum.
VersionControlLabel[] labels = sourcecontrol.QueryLabels(labelname, “$/”, tfs.AuthenticatedUserName, false, null, null, false);
if (labels.Length>0)
{
LabelVersionSpec lvs = new LabelVersionSpec(labels[0].Name);
workspace.Get(lvs, GetOptions.None);
}
As you can see, it’s really simple once you know about the LabelVersionSpec class and that you can use it with the Workspace::Get(VersionSpec, GetOptions) method.
There are several classes that derive from the VersionSpec one:
· ChangeSetVersionSpec, to get the content of a given changeset into your workspace.
· DateVersionSpec, to get the content that were checked in until the given date.
· LabelVersionSpec, to get from a label.
· LatestVersionSpec, to get the latest version.
· WorkspaceVersionSpec, to get the content of another Workspace.
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:
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:
Stay tuned!
