Team foundation Build – Share Builds among multiple servers

When you begin to use Team Foundation Server, you will create different builds for all of your company’s projects. Since building complex products can be resource intensive, it is likely that your Team Foundation Server machine starts to perform slowly. This is a typical issue of Continuous integration servers, since they compile projects at each check-in you will end with a lot of builds and a lot of work to do.

Team Foundation Server addresses this issue separating build machines from Team Foundation Server. If you find that the build machine is becoming slow, you can simply use another machine in the network to execute some of the builds. In real environment you can even avoid to install build engine in the Tfs machine, delegating builds to other servers. First of all go into another machine, fire the installer of Team Foundation Server, and choose to install a “Team Foundation Build”.

image

Note: if you do not have Active Directory you Must create in this machine an account with the same name/password of an account of the machine where Team Foundation Server is running and that account must have right to access tfs. This is a standar requirement, the Build Server needs to access Team Foundation Server to get sources to build and store build result, etc, etc. so it is of vital importance that it runs with sufficient privilege to access TFS server. If you have active directory you do not need to create a specific account, but you must select one AD user that have credential to access TFS during the installation.

When the installer finished, you can go to Visual Studio, Right Click on the Builds in the Team Foundation Server Explorer Tree, then choose “Manage Build Agents”

image

Now you can add additional Build Agent, and you can choose the new machine name, where you had previously installed the Team Foundation Build.

image

Now you can use this new machine to run Builds simply specifying this agent when you create a Build Definition, or you can use it when you manually queue new build. It is really important that the user credentials used to run the Build Service in the new Build machine has the right to access the Team Foundation Server Machine as stated before.

If you had already installed the team Build engine with a wrong user don’t panic, you can still manually change build machine settings to correctly access TFS. Go to Service control panel and change the credential used by the “Visual Studio Team Foundation Build” service to use an user that has sufficient credential for TFS. Now restart the service.

image

It is highly possible that when you restart the service you get “access is Denied” error, it means that the new account does not have sufficient rights to run, first of all the user needs rights to access the folder where you install the Build Agent, but this is usually not enough. The only way to understand exactly what is wrong is going into the Event Viewer where you can find detailed errors like this one.

Detailed Message: TF224004: The Visual Studio Team Foundation Build service failed to start because WS2008V1\alkampfer does not have the required access permissions for address http://ws2008v1:9191/Build/v2.0/AgentService.asmx.
Exception Message: HTTP could not register URL http://+:9191/Build/v2.0/AgentService.asmx/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details). (type AddressAccessDeniedException)

This message is one of the most dreadful, it means that the user has no rights to use that url to host  a web service. The solution is to run this couple of commands.

netsh http delete urlacl url=http://+:9191/Build/v2.0/AgentService.asmx
netsh http add urlacl url=http://+:9191/Build/v2.0/AgentService.asmx user=alkampfer

With these two lines of code you are giving to user Alkampfer (the one that has right to access Tfs and the one used to run build service) enough rights to create a web service in that url. Now you should be able to start the service. Verify if the Build Agent is running browsing the WebService page (something like http://10.0.0.11:9191/Build/v2.0/AgentService.asmx). Now if everything is ok, you should go to “Manage Build Agents” menu and reenable agent if necessary. This step is needed because Tfs disables all Agents that are unable to run. If you fire a build with an agent that has no right to access TFS the TFS disables that agent because it is useless. When you correct the problem, you can simply edit the Build Agent definition, and change its status back to active, now you can schedule again builds on it.

With such a configuration you can divide build tasks across multiple machines, and the whole build process is more scalable. The advantage is that you have a single point of access (the Tfs machine), and from that point you can subdivide works between machines. Since you can install how many build server you want, the whole system is highly scalable.

Alk.

Tags:

Creating a build with Tfs

I worked for long time with NANT + CC.net as continuous integration tools. I used subversion as Source Control System and use Mantis or Redmine for issue tracking.

The main disadvantage of using such a configuration is the need to make each tool communicate with others, the good part is that these tools are open source. Team Foundation Server on the other side is a Commercial tool, so you have to pay it, but it gives you a lot of features in a single unified tool, and this is Great. Let’s see as an example how to set up a continuous integration server for a simple project.

Leveraging the power of a Continuos Integration machine with open source tool is not difficult, but you need to do some work, in CC.net you have to create a NANT or MSbuild script, configure cc.net with ccnet.config and so on. The good part of Team Foundation Server is that creating a build is a matter of a right click on the builds node

image

The “New Build Definition” shows you a wizard that helps you in creating the build, the first time you run it tells you that it does not find any build file in the source code, so it suggest you to use a wizard to create one.

image

The wizard is really simple, first of all it asks you the list of solutions to build.

image

In this test project I have only one solution so I select it. Then you select the configuration (Debug/Release/Etc). You can forget any option for now. When you click finish you will return to the original wizard, now you can decide how many result you want to mantain

image

This is a great option, because it permits you to avoid keeping too many data, as example for failing builds. The next step asks you the build agent to use, since it is my first build, I create an agent for the first time

image

I’ve installed the Build Engine on the same machine where the Tfs runs, so I create an agent named StandardBuildAgent, then specify the name of the computer TFSALKAMPFER , when you press OK you can use that agent to run the build, now you must specify network share where to put the result

image

In the last step you simply decide when to trigger a build, and since I want really continuos integration I specify a build at each check-in-

image

Now the build is created, you can right click and schedule a new build (this is the equivalent to Force a build in CC.net). The result gives you a lot of informations on what is happened.

image

This build have some errors, if you scroll down the result of the build you can find detailed error, stored in file Debug.txt. This file contains the error output of the msBuild engine so you can understand what goes wrong. The good news is that, if the build goes ok, you can find a lot of information in the shared folder you specified during build definition.

image

And if you click into the Debug folder you can find all the artifacts produced by the build.

image

Respect to CC.Ner, Team Foundation Server is really simpler, with few clicks you can create a Build Definition that is triggered at each check-in, gives you a lot of detailed information, and copies all artifacts in a network share. I really care about Continuous Integration Machine, and the ability to directly manage it inside Visual Studio with few clicks is really a great feature respect CC.net.

Alk.

Tags: