In TFS 2015 Update 2, I have configured seven release agents in one pool, separated into a set of logical environments using capabilities.
I also have a release configured with three environments defined to use the queue corresponding to this pool and demands specified to filter to the appropriate servers for each environment (1-Test, 2-QA, 4-Prod).
My problem is that TFS is only releasing to the first agent created that meets the demands. If I remove all demands in an environment I would assume it would release to every agent in the pool yet TFS still releases to only the first agent in the pool. If I disable that first agent, it will release to the next; but still to only one agent.
What am I missing?
I think you're misunderstanding what agents are for. The agent merely acts as an invocation mechanism for your deployment activities. You don't need one agent per environment or per server.
For example, if you need to run a PowerShell script on a machine, you use the "PowerShell on Target Machine" deployment activity. The agent will then use WinRM to tell the target machine what scripts to run. That agent can run PowerShell scripts against any machine.
Why would you want the release or build to select a different agent every time? I had always seen with TFS that the probability of a build running on the agent, where the last successful build for a specific build definition ran, is very high.
The only reason I think a build/release should run on a different agent every time is if the number of builds running at a same time requiring the same capabilities is more than one.
If you would like to test each of the agents then try disabling one agent at a time and run the build/release.
Related
I am using TFS 2017 update 3, In TFS 2017, I have a Release Definition in which i have a command line task thorugh which I call the cli of an automation application by passing it an arguments like below
"C:\Program Files (x86)\Auto-2019-Q1\Auto-Cli" -scriptName "Driver_Smoke.xlsx" -scriptLocation "C:\Next_Gen"
and it does run the application successfully but now i have to run the same task on multiple servers where i have already configured build agents so that the automation can be executed on multiple servers at the same time.
For this, I have added an agent phase in the release definition and have added the agent name in the demands but it works only on one server and doesn't works simultaneously on the other server.
However, I can add another agent phase option and then give the agent name of another server but then i'll have to wait for the previous agent phase task to be completed. This would take a lot of time.
I tried giving two agent.name in demands but it doesn't work like that. so, is it possible to run a task on multiple servers at the same time in release definition?
I have found one workaround for this using the existing tasks in TFS Release definition. What I did is,
I have configured two deployment agent on each server.
Copied the above mentioned cli commands into the notepad and created a batch file of it.
Created a Task in task scheduler to execute the batch file whenever the build agent service is started.
In the Release definition, once the deployment of the package is done and after which we need to run the automation using the tool, I added a Run on agent task in RD and associated one of the build agent name where i needed to run the automation tool and under the Run on agent task I added 3 tasks i.e. one to start the service and two task to stop the service, you can repeat the same set of task for multiple servers where you need to run the automation tool thorugh CI.
So, here when the deployment is done the Run on Agent task gets started and it first stops the service and then it start the service due to which the task created in tasks scheduler get triggered and the tool gets executed and then you can stop the service as you no longer need the service to run.
By using this process, i no longer need to wait for a long time except couple of seconds in order to run the automation tool on multiple servers simultaneously.
I have a Windows VM that hosts a VSTS build agent. Due to the number and length of builds that are running I would like to know whether multiple build agents can be hosted on one computer? That would allow a dedicated agent for slow builds, and a dedicated agent for quick builds.
https://www.visualstudio.com/en-us/docs/build/admin/agents/v2-windows
Yes you can run multiple agents in a single VM.
Make two directories say Agent1 and Agent2, extract the agent in each one of them and configure them with different names against your VSTS/TFS account.
It should work out of the box.
We run 4 agent jobs per machine concurrently with no issues. As mentioned above, should work out of the box. Just make sure you clean up directories. We have a script to do it every night
Yes, this works, I did the following:
Created a PAT for agent installation needs
Downloaded agent binaries from the agent creation page
Unpacked the archive contents into 2 different directories ("c:\ado-build-agents\agent1" and "c:\ado-build-agents\agent2")
Ran "config.cmd" and followed configuration instructions, provided by it.
Updated pipelines to build the agent pool, which those agents reside in ("Default" in my case)
To test the setup - triggered all 15 pipelines, that I had. As the result I was able to see two pipelines running at the same time, while others were in the "Queued" state (according to my expectations).
I will be also testing out how resources are consumed by the agents to try to understand if I should deploy more agents on the build machine.
I have a MsBuild process that start as part of build using TFS Build Services 2013. I need to pass a few parameters to this process (for example the build number). I've done this previously by modifying the build template and added these parameters to the list of parameters sent into MSBuild, something that has worked fine.
I did however found that TFS Build Services writes a number of environment variables for run (build number being one of them) and as I easily can change my MSBuild script I'd rather just use these directly variables instead of modifying the build template.
My question is however how this will work when I have several build agents? Won't they write over each others values in the environment variables? Can I be 100% certain in my MSBuild script that I didn't get the build number of the next build that might have started in parallel?
Each TFS build is done using a specific build number. If you have multiple agents working on a 'parallel' build, they will all use the same build number. Each build agent will be running in their own specific environment and will not have any issue if other agents are running in parallel - the build number for one agent will not 'clobber' another during a build.
I have several integration tests within my Jenkins jobs. They run on several application servers, and I want to make sure that only one integration test job is run at the same time on one application server.
I would need something like a tag or variable within my jobs which create a group of jobs and then configure the logic that within that group, only one job may run at the same time.
Could I use the Exclusion plugin for that? Does anyone have experience with it?
Use the Throttle Concurrent Builds Plugin. It replaces the Locks and Latches plugin, and provides the capability to restrict the number of jobs running for specific labels.
For example: you create a project category 'Integration Test Server A' and tie jobs to it with a maximum concurrent count of 1, and a second 'Integration Test Server B' label and tie other jobs to it, both categories will only run a single concurrent build (assuming you've set a max job count of 1), and the other jobs in that category will queue until the 'lock' has cleared.
Using this method, you don't have to restrict the number of executors available on any specific Jenkins instance, and can easily add further slaves in the future without having to reconfigure all your jobs.
If I understand you right, you have a pool of application servers and it doesn't matter on what server your tests run. They only need to be the only test on that server.
I haven't seen a plugin that can do that. However, you can get easily around it. You need to configure a slave for each application server. (1 slave = 1 app server) You need to assign the same label to all slaves and every slave can only have one executor. Then you assign the jobs that run the integration tests, to run on that label. Jenkins will assign the jobs then to the next available slave (or node) that has that label.
Bare in mind that you can have more than one slave running on the same piece of hardware and even a master and a slave can coexist on the same server.
Did you check below parameter in the Jenkins -> Manage Jenkins -> Configure system
# of executors
The above parameter helps you restrict the number of jobs to be executed at a time.
A Jenkins executor is one of the basic building blocks which allow a build to run on a node/agent (e.g. build server). Think of an executor as a single “process ID”, or as the basic unit of resource that Jenkins executes on your machine to run a build. Please see Jenkins Terminology for more details regarding executors, nodes/agents, as well as other foundational pieces of Jenkins.
You can find information on how to set the number of Jenkins executors for a given agent on the Remoting Best Practices page, section Number of executors.
Source - https://support.cloudbees.com/hc/en-us/articles/216456477-What-is-a-Jenkins-Executor-and-how-can-I-best-utilize-my-executors
Consider TFS 2010's ability for a Build Controller to have 1+ build agents. Since builds are a subjective topic to the team/environment, consider an environment where builds are performed on commit/check-in. Each Project Collection will have 10+ Team Projects, but perhaps only 1 or 2 are being committed to in a day.
When should a TFS administrator consider creating a new build agent?
Do multiple agents run in parallel?
When a single agent is defined to a Build Controller, does it run serially?
MSDN states: "if you set up your agents to have specialized capabilities..." . What does this mean? A technology/platform differentiator? How can you setup your agents to have specialized capabilities?
How can 'tagging' build agents be used effectively in an environment where builds are (typically) performed on each check-in.
You use multiple build agents to support multiple build machines (I work currently with a build farm with 3 build machines - and thus 3 build agents - to distribute the load).
You also might want to have multiple build agents to be able to run builds in parallel. This is a nice feature to share resources, but a requirement when you start working with Test/Lab Management features.
With the capabilities: for example you can setup a build agent with version 1 of a 3rd party component, and a second build agent with version 2. With tagging you can specify in the build definition which build agent it will choose from out of the pool of build agents.
We use 2 build agents on the same machine at work, since we only have one build machine.
The first one handles our CI builds, and is tag with CI. The build definition for the CI build is set up to only use agents that have the CI tag.
The second one is for manually queued builds, mostly for the release branch builds.
I specialized the CI build agent, because it was not uncommon when we were preparing a new build for QA to have several developers check into the development branch, which would slowing down being able to release the build to QA.
One of our builds takes 9 minutes. Its nice that you don't have to be in the Queue behind it if you happen to deploy at the wrong time.