In TFS Migration Tools: Should we opt for migration or synchronization? Part 1 we explored the first thought patterns that we should be creating when considering the TFS Integration Platform (TIP). In recent discussions at a Scrum course we discussed branching and the TFS Integration Platform during one of the breaks. I nearly choked and had a stroke when I heard the statement: “oh, so I can now do a full bidirectional sync of my TFS Server environment” … NO, please read on.
Here is an extract from our TFS Integration Platform – Migration Guidance document, as part 2 of the migration investigation and guidance initiative.
The synchronization scenario can help a “soft start” or gradual migration, such as a phased migration from one version of TFS to another version of TFS. As with the migration scenario you must “keep it simple” and decide how much history is relevant. Plan proactively and be aggressive when pruning the history to be synchronized and carefully consider the latency of delta computation, migration instruction generation and actual change migration.
Less is better! Simplicity Rules!
You have a number of synchronization options, including simple, multiple and full.
- It is important to keep the synchronization load down by reducing number of filter paths in mapping. Reconsider each TIP filter path carefully, confirming that the path & associated branch is (a) stable and (b) needed. If either (a) or (b) are no, probable or unknown, scratch it from the sync list.
- … consider option 1 (simple) again before pursuing this avenue!
- Feasible if one team (Dev-1) works on the target server and another team, Dev… works on the source server, with each team working independently and working off a stable and mirrored integration (main) branch.
… avoid this option at all cost! This is skull and cross bones country, with high complexity and maintenance costs.
… OK, I feel a little better now and hope that future break-out discussions will be less stressful 🙂