Could somebody please explain the difference between build and release agents in the simplest of terms? This relates to Azure DevOps. I find info on build agents from Microsoft but I haven't found anything specifically for release agents. I'm not a developer by trade so if somebody could clear this up I would appreciate the help.
Asked
Active
Viewed 1,186 times
1 Answers
3
Technically they are the same. I.e. the agent that is used by a build or a release is the same code running on a machine. However there are 3 modes of use.
Agent pools are a way of grouping agents together. For example you might group agents together by
- Operating System (Linux vs Windows vs MacOS)
- Capabiltity (.net build agents vs Java build agents vs IOS build agents vs agents with web browsers installed for automated testing)
- Function (build vs test vs deploy)
- Network Access (Some agents can talk to certain resources on the network)
- Or a mixture of all of the above.
The more generic your agents are the better utilised they will be, but there are reasons why you might not want a single large pool of agents that do everything.
If your deployment process runs remotely, i.e. the agent connects to a remote server using a tool such as ansible or ms deploy then you can use these agents to release your code, however there are a couple of other ways to use agents to release software.
In classic pipelines (GUI created release processes) then you can also create a deployment group. In this mode you install the agent on the machine you want to deploy to, and the deployment group acts as a way of grouping sets of servers in to an environment with each agent responsible for deploying code to the server it is running on. You can tag agents in a deployment group so that only specific jobs will run on those agents. E.g you might have 5 servers in an environment, 2 web servers, 2 application servers and a database server, You can tag the agents as "web" "app" "db" and then in your release pipeline tag your jobs, this way the pipeline knows where to run each job. it can also parallelise the running of the jobs so both web servers deploy at the same time.
In multi stage pipelines (YAML pipeline as code) there is the concept of an environment. This can be a group of resources. At the moment environments support 2 types of resource.
- Kubernetes namespaces
- Virtual Machines.
As with deployment groups environments allow you to specifically deploy the agent to a Virtual Machine and then use that to run a specific job using tags.
There are 3 main benefits to using agents in either "Deployment Groups" or "Environments"
- The agent is local to the machine its deploying to meaning your release process doesn't have to cater for working over a network.
- Security, the agent talks to azure devops over port 443 which means that you can have pretty strong rules on inbound traffic to the server as only outbound over 443 is required for the agent to work
- Cost, Agents in pools are subject to rules around parallel jobs. Deployment Groups and Environments* are not part of this limit
*Environments and YAML pipelines are currently in preview and the pricing model may change when they go in to general availability
James Reed
- 255
- 3
- 8