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.
Related
I am unable to find any documentation on wiki which details approach for SSH/RDP into the ADO agents. Will be good to know the approach for both BTL/ATL agents.
The Microsoft hosted agents? You don't. You can't. They are assigned when the pipeline is queued and immediately deprovisioned after the pipeline finishes running.
Your own on-premise/self-hosted agents? The same way you'd SSH/RDP into any other machine. If you're having trouble with that, that's something for you to discuss with your networking / infrastructure team.
If you are using a Microsoft hosted then you can not per the documentation. The agent is created on a one-time instance and then torn down as soon as the build is completed.
Microsoft-hosted agents do not offer:
The ability to remotely connect.
The ability to drop artifacts to a UNC file share.
The ability to join machines directly to your corporate network.
The ability to get bigger or more powerful build machines.
The ability to pre-load custom software. You can install software during a pipeline run, such as through tool installer tasks or in a
script.
Potential performance advantages that you might get by using self-hosted agents that might start and run builds faster.
The ability to run XAML builds.
If you are using a self-hosted machine running the agent, then you'd just SSH/RDP into the server like any other and check the work folder.
I'm running Azure pipelines on a Windows self-hosted agent. One of my pipelines can do both a 32-bit build and a 64-bit build. I want to use the matrix and maxParallel capabilities to do both builds at once, on the same agent, to save time.
This isn't possible, because the 32-bit build and the 64-bit build both write to the registry, and whoever gets there second, errors out.
The obvious solution is to get a second Azure VM and run a second self-hosted agent on that VM. But I want to see if I can run the two build tasks as two different users, on the theory that they will then write to their own HKCU and not clobber each other.
This would require the default pipeline to trigger a second pipeline, or perhaps run a template, and run it as a different user.
Can this be done?
OTHER USEFUL INFO:
On an Azure DevOps skill-level scale of Beginner-Intermediate-Expert, I'm smack in the middle of Intermediate. Still learning.
The build step uses the built-in VSBuild task.
You can trigger a second pipeline (i.e. by using Trigger Build Task), but pipelines don't have a concept of running as a user - they run on an agent. That agent runs as specific user and it would be tricky to try and execute code as a different user.
Running a second self-hosted agent is a good direction. You don't necessarily need another VM - you could run another agent on the same machine, but as a different user, using different work directory.
You could use agent capabilities and demands to fine tune which kind of build runs on which agent.
This questions makes clear you can run multiple build agents on a single machine, by having one agent per directory e.g. c:\agent1, c:\agent2: VSTS build agents - Can one computer run multiple build agents?
But, when configuring these agents can they use the same work folder or must they be distinct e.g. c:\builds\ Vs c:\builds\1 c:\builds\2?
According to the MS docs:
The work directory is owned by a given agent and should not share between multiple agents.
In general, build agents check out the source code into the working directory, and then work with the sources being pulled from the repository. If you allow two agents to point to a single directory, you'll end up with a mess and unpredicted build results, at the very least.
I think one special case could be if you disable the option to check out the source code, and in this case build agents just run certain embedded scripts. But it's not a common case, anyway, and if you never share the working directory between the agents, you're always on a safe side.
In my current organization we are using Azure DevOps Server (on-prem) to release our products. The current setup is that we have a bunch of build and release agents running on a set of VMs.
The servers that we actually release to are different machines than the ones running the release and build agents, therfor we end up using alot of "PowerShell on target Machine" tasks during the release to configure and setup dependencies for our products.(asp.net websites in this case)..
However.. what I find strange is that due to this setup we cant really utilize other tasks to setup our environment/target-machines. For instance, lets say that we would like to use the "extract files"-task, then this would not be possible since the extraction would happen in our agent and not in our environment/target Machine.
Are we missing something or are you actually supposed to basically only use the "PowerShell on target-machine"-task for such a scenario?
You are right, most of the tasks are running on the machine of where the agent is installed. if you want to run the agent in one VM and deploy with this agent to another VM you can use out-of-the-box with the PowerShell on target machine or Copy files to remote machine, or SSH tasks.
But, in the marketplace you can find many tasks that can do things to remote machines, include zip or unzip files.
If you can it's really recommended to install the agents on your target machines.
I'm fresh in the area of CD/CI and I need to implement it in an old project from my company. From what I have read we have a couple of options like Azure DevOps or Team City, I chose these two options because most of our projects are built in Microsoft technologies.
I have been reading for a while, but I cannot grasp the proper definition of a Build Agent; also, I found this old question, but the answer is unclear:
In Team foundation server what is build agent and controller?
Further, I read different documentation:
Azure Pipelines agents
Build Agent
And their definitions are the following ones:
An agent is installable software that runs one job at a time.
Microsoft
A TeamCity Build Agent is a piece of software that listens for the
commands from the TeamCity server and starts the actual build
processes. JetBrains
However, I cannot understand exactly their role or purpose, do they build the Test, UAT and Production pipelines in parallel to see if the compilations were successful? Like here:
Or what do they do? Since the solution has multiple projects inside maybe 8 or 10.
You can take the example that I gave in the comments below:
Let's suppose you create a project in Azure DevOps for your new CRM
for a Dentist with a Debug, UAT, and Release environments plus a team
of 5 devs. What would represent these agents?
Thanks for any explanation.
It's analogous to a human "agent" who has different skills. Think of Build Agent as computer process that has certain capabilities to perform a build.
Some agents can perform certain jobs (e.g. build Apple specific programs), while other agents are more general purpose. Sometimes a computer can have multiple agents that can work in parallel, other times computers only have a single agent assigned to them.
Edit - Added the following to address additional questions:
Agents can be "local" which means they are on the server where the build software (e.g., Azure Pipelines, Bamboo, Team City). They can also be "remote" or on a different computer. A remote agent may be needed to build Apple specific software as this software often needs a Mac to compile.
Extending the human "agent" with different skills analogy, agents can be assigned jobs. So one agent may be assigned building software in your pipeline while another agent is busy handling deployments to different environments. Since each "agent" can only do a single job at a time, more agents can speed up build pipelines by allowing parallel jobs.
In Azure Devops,there is a left Navigation called pipelines where you need to create a build pipeline(with certain tasks) which actually requires an agent to perform the tasks.
In general,build agent/agent is a hosted machine with necessary capabilities(in case of Azure devops) used to run the predefined tasks as per the build pipeline setup to build the source code and make it available for deployment