We currently use TFS 2008 and have build agents on multiple build servers. I came across this article Configuring Multiple TFS Build Services on one Machine which details how to set up multiple agents on one machine and this is a route we'd like to take.
I've set up a new server with 3 agents on it based on the details in the link and each agent has it's own drive on the server to build to.
If I build a project using any one of the agents by itself then it works fine however if I build the same project on each agent at the same time then a very odd thing happens.
Basically two out of the three builds will fail. What I can see in the build output log file is that although the build starts out on the correct drive, at some point during the build it then swaps to the output drive the second agent is using. The build on the second agent will then change to the drive of the 3rd agent and ultimately the 3rd build succeeds.
Each of the build agent services have their own .config file, they all have different port numbers and the properties of the agents are all building to different drives.
Has anyone experienced anything like this before?
Many thanks
You are trying to do something that is not supported by default and I am not surprised that it does not work. You should upgrade to TFS 2013 and move to the Controller/agent model. In TFS 2010+ you can run multiple agents on one box by design.
Related
So I am using VSTF with some On Site build agents. A Windows Machine and a Mac for Xanamarin.iOS and Xamarin.Android builds and TFS for source control
Each time the build definition runs it creates a brand new workspace where it downloads and builds my application. This means that my list of TFS workspaces grow ever increasingly and that my build agent's hard drive fills very quickly.
I have changed the Clean setting in the Repositories tab to true. Which I got from this question.
This works fine for my Windows build agent but does not work for my Mac Build agent.
Am I missing something on my mac build agent?
Aside: Currently my Mac build definition always fails but that doesnt seem to affect the Windows build agent
This sounds like a legitimate bug in the Mac/Linux agent. You should open an issue on their GitHub page:
https://github.com/Microsoft/vso-agent/issues
Our plan is to use Team Foundation Build service to do automatic builds, then use the testing facility to automatically perform testing on the build server then release that build onto the application server.
So far we have
Team Foundation Server with TF Build Controller configured
Build server with win2012, Visual Studio 2013 and Build agent configured.
SQL Server with SQL 2013 installed
Application Server with Win2012 and .netframework installed
My question is what do I need to do to set up automatic builds, and to execute the unit test harness once compilation is successful.
Also the deployment target machine will initially be DEV, however we would like to quickly build for test env and prod etc.
This is what I got so far.
Build Controller (Already set up I believe)
Build Agent (Already installed on build server)
Build Process Template (Do I need to do anything with this. Is this what controls the whole lot)
Team Build Definition (I had a look at this, and it seems to use the build process template)
Drop Folder (I am assuming this is where the executables will be dropped into).
At the moment I have bits and pieces of info, what I would like to know is how this whole thing is hanging together. From the moment the developer wants to do the build to the moment that exe is placed into the DEVAPPSERV (Development application server).
Is anyone able to point me in the right direction or give a summary of what I need to make this happen?
Many thanks,
Dalibor
Install TFS Server (TFS Disk) Create a Team Project Collection and any desired Projects
Install TFS Controller + Agents onto a dedicated machine (TFS Disk) Configure only the build options if on a different machine to the TFS Server
Configure Build Controller to connect to a Specific Team Collection on your TFS Server
Install VS Premium or higher on build machine, if you want code coverage results for your tests
Add some code to TFS Source Control
Create a Build Definition using the default template.
Configure the build definition.
Set the working folder for the build, include only what you need as this will speed up the process
Point the definition to your .sln or proj file.
Ensure testing is enabled and that your test assembly names will match the regex used to identify test dll's i.e. name your test assemblies with the word test.
Set the trigger to be CI or what ever flavour of build you require i.e. gated build
Save the build definition
Trigger a manual build and debug any issues
you should have the basics done and a repeatable build created.
That should cover the basics, you may want to customise the build template (see Ewald Hoffman's guide for tips), you may want to narrow down your code coverage (look for runsettings file info).
If you follow these steps you should be able to get a basic build created and running from these, if you hit any issues you can come back and ask specific questions about a particular area
In order to do automatic builds you should check the CI build option ( under the trigger build option ) and third party automated testing can be run by executed by a post build script.
See the following TFS article about post build scripts.
http://msdn.microsoft.com/en-us/library/dn376353.aspx
I'm using TFS 2013 on premises. I have four build agents configured on a Build machine. Several build definitions compile ASP .NET websites. I configured the msbuild parameters to deploy the IIS application to the integration server, which sits out there in Rackspace.
By default webdeploy does differential deployments by comparing file dates. In my case that's a big plus because copying files from our network to Rackspace takes quite some time. Now, in order to preserve file dates the build agent has to compile the same base set of source code. On every build only the differential source code yields a new DLL, minimizing the number of files deployed.
All of that works fine, with a caveat: a given build definition has to be assigned to a build agent (by agent name or tag). The problem is I create a lot of contingency when all builds assigned to the same agent are queued up. They wait in line until the previous build is done.
In an ideal world any agent should be able to take care of any build, but the source code being compiled has to be the same, regardless of the agent.
I tried changing the working folder of all agents to point to the same location but I get an error because two agents can't be mapped to the same folder. I guess there is one workspace per agent.
Any ideas?
Finally I found a way to do this. Here are all the changes you need to do:
By default the working folder of each agent is $(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath). That means there's one working folder per BuildAgentId. I changed it so that all Agents share the same folder: $(SystemDrive)\Builds\WorkingFolder\$(BuildDefinitionPath)
By default at runtime the workflow creates a workspace that looks like "[BuildDefinitionId][AgentId][MachineName]". Because all agents share the same working folder there's an error trying to create each separate workspace. The solution to this is in the build definition: Edit the xaml and look for an activity called "Get sources from Team Foundation Version Control". There's a property called WrokspaceName. Since I want to have one workspace per build definition I set that property to the BuildDetail.BuildDefinition.Name.
Save your customized build template and create a build that uses it.
Make sure the option "1. TF VersionControl/1. Clean workspace" is set to False. Otherwise the build will wipe out all the source code on every build.
Make sure the option "2. Build/3. Clean build" is set to false. Otherwise the build will wipeout the output binaries on every build.
With this setup you can queue up the same build on any agent, and all of them will point to the same source code and bin output. When the source code changes only the affected binaries are recompiled. I have a custom step in the template that deploys the output files to IIS, to all the servers in our webfarm, using msdeploy.exe. Now my builds+deployments take one or two minutes, because only the dlls or content that changed during the build are synchronized to the servers.
You can't run two build agents in the same folder. The point of build agents is to run multiple builds in parallel, usually on separate PCs. If you try to run them on the same source code, then (a) it's pointless as two build of exactly the same source should produce identical results, and (b) they are almost certainly going to trip over each other and cause the builds to fail or produce unexpected results.
If you want to be able to build and then deploy a series of versions of your codebase, then there are two options:
if you queue up multiple builds, then the last one will "win", so the intermediate builds are of no real value. So if you check in New code before your first build completes, you may as well stop the active build and start a new one. you should be asking yourself why the build is so slow, or why you are checking in changes so often that this is necessary.
if each build produces an incremental update to the deployed result, then you need to pass the output of your builds to some deployment agent that is able to diff it against the deployed version and send only the changes to be deployed. This could be set up to gather results from multiple build agents if that would be beneficial.
but I wonder if perhaps your build Is slow because you are doing a complete build each time (which cleans the build folder, gets all the sources, and does a full rebuild), when what you want is an incremental build (which gets the latest changes, compiles only what is affected, and complete quickly). perhaps you should investigate making your build incremental.
I have sucessfully setup two machines. The first machine uses as TFS Build Controller and the other machine use as TFS Build Agent.
There are two things I want to do.
Run SQL scripts on TFS Build Controller machine. I have all SQL script files on TFS but I have no idea how can I get it run.
I want to do is upload the output (dll and exe files) from TFS Build Agent machine back to TFS Build Controller machine then run test on this machine. (I want to run test after I run all sql script files)
Please let me know if this is possible or not. You can just give me a link since I know it might take a long explanation. I would appriciate if you could write down the answer. :)
Yes, that is all possible, but I would strongly suggest not using the Build Controller for that. Build Controllers are meant to just dole the builds out to the Agents that do all the work. Also Build Controllers are typically shared between Team Projects, so if a single Team Project is abusing the Controller it can affect others; whereas Build Agents are usually dedicated to Team Projects. You should be able to run your SQL Scripts and tests on the Build Agent, that's what most people will do.
Having said that, if you're set on still doing it, you can modify the build workflow template to accomplish it. Anything inside the Run On Agent activity runs on the Build Agent, anything outside of that runs on the Build Controller. See Ewald's Blog series on customizing TFS Build if you've never done it before: http://www.ewaldhofman.nl/post/2010/04/20/Customize-Team-Build-2010-e28093-Part-1-Introduction.aspx
I have created a lightly customized TFS build process template and also appropriate TFS build definition. It builds fine on the TFS build server.
Is there any way I can allow developers to reuse the same build process XAML and definition to do full builds on their local machines? Maybe there is some utility which can be run with TFS build process XAML files?
I really would like to avoid maintaining a separate copy of the build script for full local rebuilds.
The build templates can only be run by the TFS build service. Without installing that on each developers machine, that might not be the best idea.
An alternative is to setup a share on the developments machine and grant access to the TFS Build account (the one that TFSBuildServiceHost.exe runs on the server as). Then the developer can Queue a build and get the Server to Drop the files onto their machine.
The downside to this is you need a lot of builds to be run on the Agents.