Поделиться через

TFS Migration / Integration / Extensibility

  • Статья

In my experience, people tend to like TFS when they see it and a typical next question is "How can I start using it with my existing systems?"

Unless you're starting from scratch, what this typically boils down to is a question of once-off migration vs. integration. Migrating from Visual SourceSafe is an example of the former, where you take your existing codebase and transfer it to Team Foundation source control, preserving version history / labels etc. in the process. That's a pretty clear-cut scenario - and let's face it, after using TFS version control you're unlikely to revert to SourceSafe, so it's a uni-directional and once-off task per project.

Less clear-cut, however, is the situation where you may have a bespoke tool for requirements management, with bugzilla for bug tracking and so on. How you can migrate to TFS to take advantage of its ALCM features and have it co-exist with some of your legacy systems? How can you fit these systems into the workflow that TFS enables? For example, if someone updates a bug in bugzilla how does that change may its way into my list of bugs in Team Explorer in Visual Studio? Then when I mark that bug as closed how is that change propagated back to bugzilla?

This is where the TFS Migration and Synchronization Toolkit can help. As the name suggests it's aimed at building tools for migration and synchronization with other version control and work-item tracking systems. Essentially it allows you to hook up datasources to the synchronization engine which generates change lists. Included in the pre-release are two reference implementations, one for version control synchronization and one for work-item tracking synchronization.

This is still early days for the toolkit - so here's the best bit: the Issues List allows you to enter and vote on what migration/sync tools you'd like to see the community develop. Take a look at the TFS Migration Blog for how they see this working.

 

The Extensibility part of the title above refers to the Team Build Object Model in Visual Studio 2008 ("Orcas") Team Foundation Server, which is new. Using the object model you can programmatically

    • create build definitions
    • queue builds
    • kick off builds
    • query build details
    • manipulate build properties

How you use this is up to you - but one suggestion I've seen is to incorporate automated builds into your workflow. You can get started with the object model in Orcas beta 1.

Cross posted from ronang's blog