TFS Integration Platform – Asking the right questions
The dust is settling after the TFS Integration Platform “Alpha” shipped, although the downloads indicate that the dust is far from over.
While the platform team is working on the BETA release, the Rangers are continuing with the samples for the custom adapter developers and helping partners to figure out what needs to be planned for a potential migration. While the migration guidance, getting started and other documentation, which you can find on the Codeplex site, will get you into the right mindset and prepared for a possible migration or synchronisation, a great deal of planning and analysis is needed to make the experience a painless and successful one.
We have started creating a batch of questions that we feel should be asked and answered. To ensure that we close the loop as much as possible, we would appreciate if you could give the list a quick scan and give us your comments in terms of the questions.
If you have a need for migration and synchronization I recommend that you visit Team Foundation Server Migration and Integration Solutions as your first stop and then TFS Integration Platform.
Version Control Specific
What migration / synchronisation type are you considering?
What is your definition of required history?
What volume of data in terms of MB and number of files is involved?
What is the overall project structure?
What is the priority/ranking of migrating/sync’ing the project version control?
What does your branching structure look like on the source?
What does your branching structure look like on the target?
Is it necessary to keep current parent-child relationship between branches ?
What are the dependencies between projects ?
What is the manual process of migrating/sync’ing the data?
What trigger are you expecting? Manual or automatic? In case of latter timer or event based?
What is the evaluation and validation process and criteria? What makes the use case a win?
-
What migration / synchronisation type are you considering?
What is your definition of required history?
What are the linking requirements?
What volume of data in terms number of work items and revisions is involved?
What is the overall project structure?
What is the priority/ranking of migrating/sync’ing the project work items?
What does your process template (fields and states) look like on the source?
What does your process template (fields and states) look like on the target?
What are the field and state mapping rules?
What trigger are you expecting? Manual or automatic? In case of latter timer or event based?
What is the evaluation and validation process and criteria? What makes the use case a win?
Are we supposed to migrate attachments ?
Are there any many-to-one field mappings ?
We have not forgotten the time and capacity planning, which is the area that is still marked as “under construction” on the migration guidance poster you find on Codeplex.
Comments
- Anonymous
November 26, 2009
Version Control Specific What migration / synchronisation type are you considering? Two-way SVN <-> TFS What is your definition of required history? Reflect history at a file-level What volume of data in terms of MB and number of files is involved? 4,000 files, representing 100 MB of data What is the overall project structure? 3 projects, 18 solutions What is the priority/ranking of migrating/sync’ing the project version control? What does your branching structure look like on the source? None. What does your branching structure look like on the target? None. Is it necessary to keep current parent-child relationship between branches ? No. What are the dependencies between projects ? Nothing special? What is the manual process of migrating/sync’ing the data? None. What trigger are you expecting? Manual or automatic? In case of latter timer or event based? Automatic, when a checkin occurs on source What is the evaluation and validation process and criteria? What makes the use case a win? Reliability and ease to setup! Work item Specific What migration / synchronisation type are you considering? Two-way JIRA <-> TFS What is your definition of required history? Per work item, maily comments are important What are the linking requirements? Be able to mark dependencies and duplications What volume of data in terms number of work items and revisions is involved? 2000 work items, roughly 10 revisions/WI What is the overall project structure? 1 project What is the priority/ranking of migrating/sync’ing the project work items? What does your process template (fields and states) look like on the source? Standard JIRA template What does your process template (fields and states) look like on the target? Custom WI which mirrors standard JIRA template What are the field and state mapping rules? 1:1, mapping generally based on lookup values What trigger are you expecting? Manual or automatic? In case of latter timer or event based? Time-based (eg 10 minutes) What is the evaluation and validation process and criteria? What makes the use case a win? Reliability and ease to setup! Are we supposed to migrate attachments ? Yes Are there any many-to-one field mappings ? No