If you’re a TFS 2008 user who’s thinking about installing TFS 2010 Beta 2, you may be wondering what will be involved in getting your existing build definitions to work in 2010. You see, build definitions in TFS 2008 are entirely automated using MSBuild. Whereas build definitions in TFS 2010 only use MSBuild for source code compilation and use Windows Workflow to orchestrate everything else that happens during the build process (setting up the workspace, running tests, indexing sources, copying binaries to the drop folder, associating changesets and work items, etc.). We refer to this workflow (it’s actually a XAML file) as a build process template. Naturally, you may have some questions about how this will affect your investment in automation your TFS 2008 builds.
Here are answers to some of the most common questions I’ve heard so far. Please let me know if you have any other questions.
No, they won’t. You’ll need to install the TFS 2010 build service. It’s included in the same setup as the TFS application tier and you would generally set it up on a dedicated build machine. If you’re just doing nightly builds, however, and not doing a steady stream of continuous integration builds, it’s fine to install it on the same machine as your application tier. I recommend reviewing the help topic on Understanding a Team Foundation Build System before deploying more elaborate build infrastructures. After upgrading from TFS 2008 and setting up build services for TFS 2010, you’ll want to review each of you active build definitions and set the default build controller appropriately (see the Defaults tab of the Build Definition editor).
Yes, you can. Even though they both default to the same port (9191), they can share that port without any problems.
It depends on what you’re building. If you install the TFS 2010 build service on a clean machine, it will install the .NET 4.0 Framework which includes MSBuild. It will also install the components necessary to support the following:
Unfortunately, the .NET 4.0 Framework is missing some of the tools necessary to build projects targeting the .NET 2.0 and 3.x Frameworks. For Beta 2, you can install the Windows SDK or Visual Studio 2010 Beta 2 on the build machine. If you need to build SharePoint or Office (VSTO) projects, you’ll need to install the appropriate SDKs or Visual Studio.
No, you won’t. TFS 2010 includes a special Upgrade build process template that mimics the behavior of TFS 2008 builds by invoking MSBuild on your existing TFSBuild.proj file. TFS 2010 will even let you use new features like gated check-in and shelveset builds.
The default build process does make it easier to make certain customizations to your build definition using build process parameters.
If you’re using the Upgrade build process template then, yes, you absolutely can continue using your MSBuild tasks. If you choose to use the Default build process template for new build definitions, the answer is a little more complicated. For actions you want to perform during the compile phase of your build, you can customize any of the projects getting built to use whatever custom MSBuild tasks you wish to use.
If, however, you want to perform actions at some other stage of the build process (e.g. after running tests), it becomes trickier to invoke an MSBuild task. You would need to create a special .proj file invoking the custom task you wanted to use and modify the build process template by adding an MSBuild activity that builds your that .proj file. Alternatively, you could create a custom workflow activity to do what you need to do and integrate that into your build process template. I’ll have blog post up later this week covering that topic in detail.
Yes, here are the steps to configure the TFS 2008 Build Agent to use MSBuild 4.0 to build your VS 2010 solutions:
<program files>\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TFSBuildService.exe
Of course, you’ll need to have .NET 4.0 installed on the TFS 2008 build agent. For Beta 2, I’d recommend installing VS 2010 on the TFS 2008 build agent machine. Let me know if you have any questions.
Sort of. We’ve changed the default working directory for TFS 2010 build agents to <systemdrive>\Builds rather than putting it beneath the build service account’s temporary directory. We’ve also shortened up the overall path to the working directory for a particular build definition to reduce the odds of you hitting the 260 character path limitation in Windows.