Using Team Build with VSS or your own source control

So - you saw Team Build and liked it's cool features that show which check ins went into the build, what work items were resolved in the checkins that went in, running unit tests as part of the build process and displaying results in that nifty little table on the build report. But, what if you have your own source control system? You may not want to use the VSTS source control system right away since you have a huge repository on VSS or maybe some other source control system. What then?

Team Build builds a sequence of MSBuild targets bunched together in a file called TFSBuild.proj on the build machine. One of these targets has the "Get" task that syncs source code from your source control system. Now, the default task that we ship has this task getting code from the VSTS Source Control server. So, now if you write a custom task that gets code from your own source control, you should be done. But, wait - what about the integration aspects? Which checkins went in and which work items were resolved/associated are going to be churned out in further tasks like GetChangesetsWorkItemsList that integrate with VSTS Source Control system. Alright - say you deleted those tasks from the TFSBuild.proj file. Then what? One more problem - apart from these tasks, Team Build also syncs certain config files (the very TFSBuild.proj that you are building on the build machine plus some other files) from VSTS Source Control itself. This is inbuilt in the product though. Which means you have to have these on the VSTS Source Control in a hierarchy that Team Build expects. So, theoretically, even if you replaced all your TFSBuild.proj tasks that interact with VSTS Source Control with custom tasks that interact with your source control instead, you would still have to have the VSTS Source Control in place to store your configuration files created each time you create a build type.

Well, so the short answer to the q then would be that we don't really recommend users to use Team Build to integrate with your own custom source control system. However, we do want to know how important this scenario is to you. On one hand, we do understand that migrating to a new system could be painful and you might want to do this one step at a time and source control would probably be the last item due to it's size and indispensability. So, for folks looking to do incremental adoption of VSTS, you can't move to Team Build first and VSTS Source Control, next really. But, on the other hand, Team Build has this great set of integration stufflike reporting changesets, work items associated etc. that we believe are really some of the most compelling set of features in the product. Using your own custom source control would not really let you benefit out of those scenarios. And, if your intention is to do incremental adoption, one option would be to use VSSConverter, a tool that migrates source code from VSS to VSTS Source Control. When you run the converter on your existent code base and migrate your code to VSTS Source Control, you could launch Team Build on that appropriately. Scheduling incremental migration every night on your original source code base will port daily changes to the new Source Control and Team Build will build these new bits too.

What is your take on this? Are we being naive in assuming whatever we have? Or is this the best possible option to work with? Do share your thoughts...

Comments

• Anonymous
  April 12, 2006
  Anutthara talks about using Team Build with VSS or your own source control.
  
  Paul Whitaker blogs about...