While dogfooding the TSF Migration Tools Getting Started Walkthrough for the umpteenth time, I was suddenly staring at a problem I had never seen before and one that I could not understand. What followed was a restore of base snapshot and reproduce the issue … which took me a while, because I obviously did not make any notes when I started to deviate from the walkthrough script … unintentionally.
This is the summary of events, which raises one VSTS and one TFS Migration Tools issue.
What the walkthrough introduces is the concept of having a Team Project A on Server A and Team Project B on Server B. As we are working with a virtual single server ATDT Team Foundation Server (TFS) environment (Server A == Server B). Team Project A (TP-A) is a team project that is currently in use by Team A and B. Team Project B (TP-B) is to become a mirror for Team B, until Team A is able to move across to Server B as well. A hypothetical scenario could be a team working on TFS 2008 and another moving over to TFS2010 in a phased migration.
In essence we:
- Make changes in TP-A, then run a bi-directional synch between TP-A and TP-B. Changes flow from TP-A to TP-B.
- Make changes in TP-B, then run the bi-directional synch again. Changes flow from TP-B to TP-A.
So far so good … if only I had stuck to the script.
Actual walkthrough Step-Step … in non-verbose mode
- Run bi-directional synchronisation between TP-A and TP-B. WIT and VC data, including history moves across from A –> B in this case.
- Make a code change in TP-B.
- Check-in pending changes in TP-B and link to a work item, creating changeset TP-B:18.
… this is where the problem started!
- ISSUE #1: Be careful against which team project you link to. I only realised on the umpteenth iteration that I inadvertently linked my check in in TP-B to a work item in TP-A. I am not convinced if the crossing of team project boundaries warrants a warning to avoid such often unintentional links … what do you think?
- Looking at history we see changeset TP-B:18, linked to work item TP-A:27.
- Looking at work item TP-A:27, we see a link back to changeset TP-B:18.
- Realising our mistake, we check-out the code and check in with a link to a work item in TP-B.
- Looking at history we see changeset TP-B:19, linked to work item TP-B:114.
- Looking at work item TP-B:114, we see link to changeset TP-B:19.
- Run bi-directional synchronisation between Team Project A and B. WIT and VC data, including history moves across from B ->A in this case.
- Looking at changeset TP-A:21, which relates to changeset TP-B:19 in TP-B, the link to the work item is present.
- However, looking at changeset TP-A:20, which relates to changeset TP-B:18, the link is gone. Huh?
<<<< This is the problem child. I expected it to be linked to work item TP-A:27.
- Issue #2 has risen out of the murky waters!
So what is issue 2?
ISSUE #2 – Beware of cross team project links, which could result in potential cross migration source links.
What we are illustrating in Hyung’s diagram is the following:
- System A has one team project and system B has 3 team projects, whereby TP-C and TP-D can be ignored for this scenario.
- The left side of the vertical line represents the left side of the synchronisation pipeline (migration source A) and right side the other side (migration source B).
- Migration Source A defines system A and migration source B defines system B. Even though we are running on a virtual machine, a single ATDT environment and both migration sources are on the same server, the synchronisation pipeline sees them as two separate systems and enforces the vertical line.
- Our changeset TP-B:18 on system B could have have links to work items in all three team projects on system B (TP-B,C,D), which is a valid scenario.
- In our scenario, however, we tried to simulate a cross-link to work item TP-A:27 to a changeset TP-B:18, which is not supported. In essence we, or rather I in this case, got all muddled up, not seeing the obvious.
To unravel our grey matter, let’s re-draw the picture with a possible scenario we may be facing soon.
- Phase 1: We have teams A and B working on a TFS 2008 server, with team projects TP-A1 and TP-A2. Team A works on both TP-A1 and TP-A2, whereas Team B works only on TP-A2.
- Phase 2: The organisation decides to implement a TFS2010 server and would like to mirror TP-A1 and TP-A2 to the new server as TP-B1 and TP-B2. Team B will move over to the TFS 2010 server, while team A will remain on TFS 2008 until certain deliverable milestones are met.
The flow of changes is TP-A1 --> TP-B1, TP-A2 –> TP-B2 and TP-B2 –> TP-A2.
- Phase 3: Shutdown TFS 2008 server.
The following illustration attempts to visualise this phased migration:
When considering using the TFS Migration Tools, it is important to (1) put on your thinking cap, (2) plan the migration, (3) go back to (1) until you have analysed the migration challenge from all angles.
The next important step is to consider the size of the migration and plan the hardware, bandwidth and especially time requirements. Test and experiment in a test environment, testing both with representative data content, volume and load, before rolling up your sleeves and wiring up the production environment.
We will be talking about the latter in much more detail once our dogfooding exercise information becomes available.