Getting Started with TFS Dependency Replicator

Continuing with the theme of releasing some of our internal tools as open source I have just uploaded the source and created a release on CodePlex for another tool that we have been using for a while called TFS Dependency Replicator. The project description up on CodePlex is as follows:

“The TFS Dependency Replicator is a tool that monitors the Team Foundation Server Build Store for the successful completion of new builds, or the change in qualify status of existing builds. When a change is detected TFS Dependency Replicator looks up a configuration file in the version control store and determines if any files from the build drop location need to be copied back into the source tree.

TFS Dependency Replicator is useful for complex build scenarios where a common framework is used across a range of products and once a new build of that framework is completed it needs to be published back into the source tree in binary for so other code bases automatically start using it.

This tool saves development teams the tedious task of manually updating binary dependencies produced from upstream builds.”

Once again, as with the TFS Build Virtualizer, if you would like to get involved with this project please contact me via my CodePlex profile page.

Installing and Configuring the Dependency Replicator Component

in order to install the Dependency Replicator component you need to first download the release from CodePlex. From this zip file you need to extract the following files:

• DependencyReplicator.exe
• DependencyReplicator.exe.config

These two files should be placed somewhere on the file system of your TFS server. I would recommend “C:\Program Files\Dependency Replicator”. Once these files are in place you should issue the following command at the command prompt:

• C:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe /i “[install path]\DependencyReplicator.exe”

During the installation process a dialog will be displayed asking for valid windows credentials. Typically I woul use the build service account (e.g. [DOMAIN]\TFSBUILD) for this purpose. Once this is configured you need to modify the configuration file, DependencyReplicator.exe.config, the contents of the file are as follows.

You need to update both the name of the TFS server, and optionally the location in which the TFS Dependency Replicator will perform source control operations. This configuration shows that the dependency replicator is configured to poll the TFS build store every five seconds, you may want to revise that upwards a little bit in your environment depending on how stressed your TFS server is.

Once this configuration is complete, TFS Dependency Replicator is ready to be switched on. Issue the following command at the command prompt.

• net start DependencyReplicator

Once the dependency replicator is running you then need to put configuration files into the source code repository to control what files will be replicated from successful builds.

Configuring Your Builds for Dependency Replication

Dependency replication configuration files are stored under each Team Project in a well known location so that the tool can find it and process them when the build store is updated. The file is called “DependencyReplicator.xml” and is located under each projects TeamBuildTypes folder, for example “$/HelloWorld/TeamBuildTypes/DependencyReplicator.xml”. The following sample file shows the configuration required to have a single file be replicated from the drop folder relative path (Source) to the absolute location in version control (Destination).

Another way of configuring the dependency replicator is to not have it replicate after each successful build, but rather to have it replicate only after a specific build quality has been reached and flagged in the build store. The configuration below shows how to listen for the QualityChanged events, and the BuildQuality attribute specifies which quality level the replication activity is triggered on.

What’s next? Want to help out?

If you have any feedback please use the Issue Tracker and create a work item. Finally if you would like to help out with the project I’ve got the following roles available:

• Documentation Writer; responsible for updating CodePlex wiki and producing installation guide.
• Tester; responsible for testing installation process and operation of the tool.
• Developer; joint responsibility with me in designing and developing the TFS Depenency Replicator moving forward.

If you are interested contact me via my CodePlex profile page. Thanks for listening! I hope you find the TFS Dependency Replicator useful in your organisation.

P.S. Please note that once we get real documentation in the CodePlex wiki this page will become obsolete, but I will put a link to the equivalent documentation at the top of the page.

Getting Started with TFS Build Virtualizer

Today I uploaded the source for TFS Build Virtualizer to CodePlex under the MIT license. I have also put up a release (1.0 RTM) which is compatible with Team Foundation Server 2005 and Virtual Server 2005 R2 SP1. The TFS Build Virtualizer was originally developed by Readify.

From the project description:

“TFS Build Virtualizer is an extension to the Team Foundation Server build system which allows build masters to have a large number of virtualized build servers with Team Build installed. When a build is invoked the build virtualizer determines which build server to use to run the build and communicates with Virtual Server 2005 where it exists in a saved state.

The build virtualizer resumes the build server from saved state, and forwards the build request into the build server where it builds normally. Once the build completes (success or failure) the build server is put into a saved state once again.

Benefits of using this approach include being able to have a large number of build servers (for each team, or different build environment) and be limited by only the amount of available disk space.

The build virtualizer is designed to accommodation multiple different TFS servers and has configuration settings to restrict which hosted virtual machines developers can request access to.”

If you would like to get involved with this project please contact me via my CodePlex profile page, or, if you find any problems or requests create a work item via the Issue Tracker.

Getting Started with TFS Build Virtualizer

TFS Build Virtualizer is installed as two components. A component that is installed on the Team Foundation Server, and a component that is installed on Virtual Server 2005. These components are called “Build Virtualizer” and “Build Virtualizer Proxy” respectively.

The Build Virtualizer is responsible for mocking a Team Build instance and forwards requests to the Build Virtualizer Proxy to start up virtual machines over a WCF channel. The Build Virtualizer Proxy communicates with Virtual Server 2005 R2 SP1 via the COM automation API.

Installing and Configuring the Build Virtualizer Component

In order to install the Build Virtualizer component you need to first download the release from CodePlex. From this zip file you need to extract the following files:

• BuildVirtualizer.exe
• BuildVirtualizer.exe.config

These two files should be placed somewhere in the file system of your TFS server. I would recommend “C:\Program Files\Build Virtualizer”. Once these files are in place you should issue the following command at the command prompt:

• C:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe /i “[install path]\BuildVirtualizer.exe”

During the installation/configuration process a dialog will be displayed asking for valid windows credentials. Typically I would use the build service account (e.g. [DOMAIN]\TFSBUILD) for this purpose. Once this is configured you need to modify the configuration file, BuildVirtualizer.exe.config, the contents of the file are as follows.

First, change the endpoint that Build Virtualizer will communicate to the Build Virtualizer Proxy with. This is typically done by replacing “localhost” with the name of the Virtual Server 2005 R2 SP1 machine.

Next, specify the name of the Team Foundation Server that the Build Virtualizer will communicate with to initiate builds. You might also like to specify a “DefaultBuildMachine” to use if a build type has not been explicitly configured to use the virtualization features.

Finally, specify the names of the build servers (running as virtual machines) that the Build Virtualizer instance on this machine will be allowed to request that the Build Virtualizer Proxy starts.

Finally, in the Team Project’s build type directory needs to have a BuildVirtualizer.xml file added (sample location: $/MyProject/TeamBuildTypes/BuildVirtualizer.xml). The Build Virtualizer reads this file whenever a build is initiated:

If a mapping is missing for a particular build type, then the default build server is used. All the build types that use virtualization should then be configured to point to the local TFS server as the Team Build server (Team Build should be stopped/disabled on the TFS server). Once this configuration is done it is safe to start the Build Virtualizer on the TFS server with the following command:

• net start BuildVirtualizer

Next up, we need to configure the Build Virtualizer Proxy on the Virtual Server 2005 R2 SP1 machine.

Installing and Configuring the Build Virtualizer Proxy Component

In order to install the Build Virtualizer Proxy component you need to first download the release from CodePlex. From this zip file you need to extract the following files:

• BuildVirtualizerProxy.exe
• BuildVirtualizerProxy.exe.config
• Interop.Microsoft.VirtualServer.Interop.dll

These two files should be placed somewhere in the file system of your TFS server. I would recommend “C:\Program Files\Build Virtualizer”. Once these files are in place you should issue the following command at the command prompt:

• C:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe /i “[install path]\BuildVirtualizerProxy.exe”

During the installation/configuration process a dialog will be displayed asking for valid windows credentials. Typically I would use the build service account (e.g. [DOMAIN]\TFSBUILD) for this purpose. Once this is configured you need to modify the configuration file, BuildVirtualizerProxy.exe.config, the contents of the file are as follows.

The service endpoint address needs to be configured so that the Build Virtualizer messages are processed correctly, this should be the name that the Build Virtualizer knows the server by.

Optionally, the metadata GET URL should be updated with the host name as well:

And finally, the list of build servers that the Build Virtualizer Proxy is allowed to start and stop in Virtual Server need to be specified. The idea is that the Build Virtualizer Proxy can actually service multiple Team Foundation Server instances, but this list is the governing superset of build servers that can be worked with. The similar list in the BuildVirtualizer.exe.config file is the build servers that the users of that TFS instance can get access to. It isn’t designed to be a security mechanism, just a sanity filter.

 

Finally, once you have configured the Build Virtualizer Proxy, you need to start it with the following command:

• net start BuildVirtualizerProxy

Now to get your build servers up and running.

Preparing Your Virtual Build Servers

Once you have configured the Build Virtualizer and Build Virtualizer Proxy, you need to create a virtualized build server that they can start and stop. You may have some of these already. Once they are configured with Team Build and connected to the Team Foundation Server instance, simply go to the Virtual Server 2005 R2 SP1 console and “save state” the virtual machine. Once you initiate a build the build virtualizer should intercept it, start the build server, perform the build, and then save its state back down to disk.

What’s next? Want to help out?

If you have any feedback please use the Issue Tracker and create a work item. Finally if you would like to help out with the project I’ve got the following roles available:

• Documentation Writer; responsible for updating CodePlex wiki and producing installation guide.
• Tester; responsible for testing installation process and operation of the tool.
• Developer; joint responsibility with me in designing and developing the TFS Build Virtualizer moving forward.

If you are interested contact me via my CodePlex profile page. Thanks for listening! I hope you find the TFS Build Virtualizer useful in your organisation.

P.S. Please note that once we get real documentation in the CodePlex wiki this page will become obsolete, but I will put a link to the equivalent documentation at the top of the page.