How can I add a capability to a build agent in TFS 2015?
For example, I would like to install a build tool (on a TFS2015 build agent) and register this as a TFS Build agent capability.
I know that I can add this capability manually, through the web interface, but how to do it with a script?
I've read that TSF2015 discovers build agent capabilities alone, but.. how to instruct it about 'how to detect my build tool' ?
References
I've read so far:
http://nakedalm.com/using-build-vnext-capabilities-demands-system/
http://www.colinsalmcorner.com/post/why-you-should-switch-to-build-vnext
Credits go to Donovan Brown and its blog post
I have tried the solution it proposes, and it works in my scenario/environment:
set an environment variable during the software setup
this variable and its value will appear as agent capabilities in the TFS agent resume
According to a GitHub issue, this functionality will eventually appear in npm scripts accompanying vso-build-tasks.
In the Agent capabilities you can define custom "user capabilities"
I added a custom user capability called
"Tag" and set it to VS2015
In my build definition under General, under Demands, I added a demand that
"Tag" equals VS2015
This will now force my build to that specific Pool (or agent)
For example I installed a 3rd Party utility to one of my build agents and added to the Agent user capabilities "AutoIt" = True. In my build, under General, Demands, I added one called "AutoIt" exists, this forces this build to the agent with the 3rd party utility that is installed.
Related
I currently have an on-premises TFS 2017, a TFS build and a test that fails on the build agent but not when running locally. I heard about historical debugging but I couldn't find instructions on how to enable it on a TFS build, if that's even possible.
Is it possible to configure my build so that it generates an intellitrace file for me to debug the test run afterwards?
For intellitrace which related to the old testsettings file and could add some variables to configure this.
You could also manually enable such option in the VS on your build agent.
Also find a link mentioned it seems also work with Msbuild arguments. Even not documented anywhere in Msbuild command doc. I wonder whether IntelliTrace is still running even though it's not explicitly specified to do so
However, looks like you just want to find the root cause why your tests failed on tfs build even it passed locally.
To narrow down the issue, suggest you directly remote to your build agent. Instead of through TFS build, manually build your project, run the tests in the Visual Studio on build agent.
It will come out whether it's an environment issue. You must make sure it's the same environment for build agent and your local.
TFS is just using build service account to invoke msbuild/vstest command in build agent to run build/test.
Also make sure build service account have appropriately permission if your tests required some permission.
Developer A is member of group - 'Contributors' and 'Project Valid Users' for team project T1. He is required to perform all development activities like check-in, check-out, merge etc.
There are 3 builds configured for this team project T1. One each to build and copy artifacts to Dev, QA and Production servers.
Currently 'A' is not able to modify the build but he can execute (queue build) the builds.
We need to control this build executions. We want only few members (project owner) to execute the build (& deployment) of QA and Prod.
Please advise how to provide the authority to control the same.
This can be achieved by permissions. You can add all the project owner to the group - Project collection build Administrators. Setting the premissions to make sure only this group can queue the related build. More info about detail permissions for your reference: MSDN Link
To setting the permission, you can do this in the web portal( click the security just as below) or using tf permission command
Note: My screenshot is for TFS 15, not for TFS2015, there maybe something difference.
So, I tried to upgrade my TFS 2015 to allow project with .NET 4.6.1.
I downloaded the Targeting Pack for .NET 4.6.1, ran it, restarted the server, ran my build configuration for the build agent by overwriting the old settings, and started my builds.
Now non of them will build :(
I think I miss setting a parameter somewhere.
This is my agent, which is registered, but never requested (for some odd reason):
Am I missing something?
According to your agent.version 1.95.3, seems you are using TFS2015 update3 which should definitely support .Net 4.6.1. And the system capabilities of your agent looks okay except the Number_OF_PROCESSOR. Your value is 1, but usually the default is 8. Did you manually change the value during the configure?
Recommend you follow below way to narrow down this issue:
First check in that if the build server is available and enabled in
TFS at https://YOURCOMPANYNAME:8080/tfs/_admin/_AgentQueue, and
your build agent should be “Green”.
Make sure the agent is in interactive mode.
Try to change a domain account which is a member of the Build
Agent Service Accounts group and belongs to "Agent Pool Service
Account" role, to see whether the agent would work or not.
Double check whether there are some Firewall interface block the
build, try to disable all related settings.
If it's still not work, delete that agent and re-deploy a new one following the detail steps in this article. You can also go through below similar questions to check if there is some useful info :
TFS 2015 On-premise issues
TFS 2015 build vNext - hangs with "Waiting for console output from
an agent..."
TFS 2015 Build agent won't start
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 understand I can write my own custom activity (in C#) to execute custom logic during the build process. My understanding is that Powershell can also be used, but I am not sure where it fits in. I do understand Powershell is used for executing command line commands but how and where would I use it to customize the build process?
Thanks
The decision whether to use Powershell or a Custom activity is for me based on who is responsible. If you have an activity that is created by the build master (for TFS) and therefor reusable for all the teams in the organization, I create a custom activity.
If the project team is responsible (for example a deployment script), the I use the powershell. I create an argument where the team can enter the path of the powershell script that needs to execute to deploy. The project team can optionally choose to enter a value in that argument. The project team can also maintain their powershell deployment script themselves without the help of the build master.
So in short:
A reusable activity: Custom activity
Activity for the team only: Powershell
For me, powershell is the way to go. Here are my reasons why:
Script Independence:
You get script independence using this approach. Example: I have a number of scripts that run after the build (i.e. the compile) process has completed:
Instantiate Database
Deploy Database Code
Deploy Web Applications
Verify Deployment
Run Acceptance Tests
All of the above can be launched, debugged and tested independently without the need to queue a new build.
Powershell is easy to work with:
Custom assemblies tend to add a lot of complexity and flakiness to the solution. Example: Upgrading from TFS 2010 to TFS 2012 was very painful, because all of the Build Templates broke. We had to recompile all of our custom assemblies, and only one dev on the team knew how TFS Build was set up to run our custom activities. I have recently removed all custom assemblies from our build templates, and am using Powershell exclusively.
I have customised my process templates to call a user-defined powershell script after the TFS Build has completed. I do this by using a paths argument in the build definition. This argument is simply an array of strings pointing to the scripts. I agree with Ewald, above, that TFS does not pass the build arguments to scripts. To solve this, in my workflow template I parse each script in the string array, and replace well-known tokens with the build arguments - e.g. #(BuildNumber), #(SourcesDirectory) etc. I find this to be a very easy and solid solution.