Creating a Release: Agents
Start course
1h 2m

This course deals with how to implement continuous delivery with the Azure DevOps solution. In particular, we will be exploring how to design different release strategies and some factors you need to consider while setting up release pipelines. This will include looking at release triggers, release gates, and other areas associated with releasing code, including working with different environments. We will also take a look at deployment patterns and how they can be implemented in your release strategy and release pipelines. During this course, we will be using hands-on examples to help work through these concepts and configurations.

If you have any feedback for us about this course, please contact Cloud Academy at

Learning Objectives

  • Design a release strategy
  • Set up a release management workflow using Azure DevOps
  • Implement an appropriate deployment pattern

Intended Audience

  • DevOps engineers 
  • People preparing for Microsoft’s AZ-400 exam


  • General knowledge of Azure
  • Experience with Git version control, including pushing changes into repositories
  • You do not need to know any specific development language

To execute your pipeline, you need to use agents. Agents are the workhorse of Azure DevOps. When a task in a pipeline needs to be executed, a job is created and submitted to an agent queue to be completed by an agent. Microsoft provides hosted agents which live in the cloud and need to be able to access public endpoints like AWS or Azure. There is a variety of hosts you can select. Here is the current list. This will, of course, evolve over time. Depending on your pipeline, you may want to execute tasks at different locations, for instance, if you're using a cloud-hosted Azure DevOps instance but want to execute your pipeline tasks on your on-premise servers, the cloud agents have no line of sight to your target systems; you'll need to install a self-hosted agent. These agents will be able to talk to the cloud-hosted Azure DevOps and to the on-premise target servers.

If you need to execute these tasks in a private workspace, the Azure DevOps agent can be installed on a variety of platforms from Windows OS to macOS, Linux, and Docker, allowing for integrations into many different of environments. Agent pools allow you to group and create security boundaries for your agents. They are scoped to your DevOps organization, and agent pools can be shared across multiple teams and projects. This is because sometimes the infrastructure you're deploying to is used by multiple teams.

A queue is used to collect jobs for an agent pool, which can be backed by one or many agents. When you create your release, you can specify what queue you want to use. Queues are scoped to your team project collection, this is so that you can share them across multiple team projects.

In your release pipeline, you can organize groups of tasks into jobs. Every build or deployment pipeline has at least one job, but can also be made up of many jobs. A simple example could be you have a mixed OS environment and you have tasks you need run on a Windows machine and tasks you need run on a Linux machine. In this case, you would define multiple release jobs, targeting different agents, to help achieve the desired deployment result.

Azure DevOps has the ability to run server jobs, which run tasks on the DevOps server itself. This is also referred to as agentless jobs. Agentless jobs do not require an agent to execute the task. The list of tasks that can be executed this way are small and contain tasks like manual intervention or REST API tasks.

Containers are becoming more common in today's landscape. With a container, you can leverage existing containers built by vendors or by the community or by yourself. When you specify a container to run your tasks, the tasks will be executed inside that container.

Agents can be grouped together into deployment groups. Deployment groups are logical collections of agents that exist within an environment, for instance, Dev, Test or Production. Tasks that are targeted at a deployment group can run on some or all of the target servers, depending on the arguments you specify.

The last thing to cover in regards to jobs are Multi-configuration, and Multi-Agent. Typically, a task will run on a single agent, however, with multi-configuration, you can run the same set of tasks with different configurations. For instance, deploying the same website to different regions in Azure. With multi-agent, you can run the same set of tasks many times on a number of different agents. A good example would be a performance test, where you can run the same 10 tests on 20 different servers to validate the results.

About the Author

Matthew Quickenden is a motivated Infrastructure Consultant with over 20 years of industry experience supporting Microsoft systems and other Microsoft products and solutions. He works as a technical delivery lead managing resources, understanding and translating customer requirements and expectations into architecture, and building technical solutions. In recent years, Matthew has been focused on helping businesses consume and utilize cloud technologies with a focus on leveraging automation to rapidly deploy and manage cloud resources at scale.