0

I have installed agent on VM and configured a CI build pipeline. The pipeline is triggered and works perfectly fine.

Now I want to use same build pipeline, same agent, but different VM. Is this possible?

How will the execution happen for builds and on which VM will the source be copied?

Thank you.

Amruta
  • 701
  • 4
  • 15
  • 38
  • "Same agent, but different VM"? Why? Each VM should have its own agent, and then all VM should be in an agent pool. You cannot have an agent that runs on multiple machines, as that's technically impossible. – Lex Li Sep 25 '18 at 15:03
  • What problem are you trying to solve? A different virtual machine is going to have a different agent, period. – Daniel Mann Sep 25 '18 at 19:31
  • When she says "same agent", I assumed that she meant *copy* or identical agent. Like if you have to two identical files on two computers. They are not physically the same, but they are the same in that they are identical. – Dan Friedman Sep 26 '18 at 12:47

3 Answers3

0

Like the others I'm also not sure what you're trying to do and also think that the same agent across multiple machines is not possible.

But if you have to alternate or choose easily between VMs, you could set up for each of your VMs (used for this special scenario) an individual agent queue with one agent in that pool. That way you can choose the agent pool at queue time via the agent queue dropdown field. But that would only work if you're triggering manually, not in a typical CI scenario. In that case you would have to edit the definition to enforce any particular VM each time you want to swap VMs.

enter image description here

DanDan
  • 1,038
  • 4
  • 15
  • 28
0

NO. These private agents are supposed to have a unique name and are assigned to an Agent Pool/Queue. They are polling up to VSTS/Azure Devops server if they have a job to do. Then they execute it. If you clone a machine with the same private build agent, then theoretically the agent that picks it up will execute the job, but that is theoretic. I really don't know how the Agent Queues will handle this.

It depends on what you want to do.

  1. If you want to spread the workload, like 2 build servers and have builds go to whichever build server isn't busy, then you would create 1 Agent Pool/Queue. Create a Private Agent on one server and register it to that Pool, then on the second server un-register the agent and then re-register the agent add it to the SAME pool.

  2. If you want to do work on 2 servers at the exact same time, like a deployment to 2 servers at the same time, then you would create a 'Deployment Group' and add both servers to that. You would unregister both agents from the Agent Pool/Queue. From your 'Deployment Group' copy the PowerShell script snippet and run it on each machine. This way you can use this in your Release Pipeline and deployments in parallel, which take less time to do deployments.

Antebios
  • 1,681
  • 1
  • 13
  • 22
-1

You could set up a variable in the pipeline so you can specify the name of the VM at build-time.

Also, once you have one or more agents, you would add them to an app pool. When builds are run, it will choose one agent from the pool and use that.

Dan Friedman
  • 4,941
  • 2
  • 41
  • 65