While testing the latest TFS Integration Platform, we re-created the Getting Started Hands-On-Lab (HOL) manual to not only demonstrate some of the new features, but also emphasize the administrative value delivered by the new TFS Integration application.
But, that is not what this post is about. We stumbled over two gotchas during testing and as these have raised their heads in the field, I would like to document both.
Why are the links between Work Items and Changesets not migrating?
To migrate links between work items and changesets you have to run the migration of the work items and the changesets together, not as separate migrations. If you opt for separate migrations the link relationships will not be known and therefore not migrated.
… illustration loaned from the book .Net Enterprise Solutions … Interoperability for the Connoisseur to demonstrate the migration of data from one side to the other.
Why is my bi-directional synchronization only moving work items from left to right source, but not vice versa?
If you use the new TFS Integration application and the configuration templates, you must be aware that the templates are optimized for migrations, not synchronizations. For example, the Version Control and WIT configuration template has the following FilterItems defined:
If you do not change these, you will notice that the work items move from the source DFD526EA-386F-453A-AC13-B8FAEDE74981 to B31EB85D-3715-43AD-880C-2E2A69975F22, but not vice versa. Huh? … thanks for Bill Essary, we have a great elaboration on the configuration template.
As mentioned the configuration template is tuned for a one-way migration and it takes advantage of the shell convention to replace <SourceIdentifier> with the team project name and to set the default query on the target side to Id=0. The Id = 0 ensures that we do not read data in the right source and then do nothing with it … which is excellent for a one-way migration, but in case of a synchronization will not move any data from right to left..
The template uses “[System.AreaPath] UNDER <team project>” as the default to show people who understand TFS that a WIQL query can be used in this space. Alternatively you could leave it blank, or replace the broad query on the source side with “[System.WorkItemType] = [Any].” using the TFS Integration application you can type [System.WorkItemType] <> ‘’ in the shell, which replaces and escapes the special characters.
So, if data does not migrate as expected, double check your configuration and especially the Filter Pairs 🙂