Another topic that you might run into at some point is deploying an application to on-premises servers or servers that are behind a firewall. You may also come across situations where it is necessary to run scripts on all of the machines hosting the application or situations where the target environment does not supply a mechanism for deploying applications.

The approach to performing releases, which was shown in the Working with Azure DevOps releases section of this chapter, relies on being able to connect to the target machines or services that will host the application. We call these push-based deployments, and this is not always possible.

When deploying to target machines that cannot be connected to, another approach needs to be taken. This approach is called agent-based deployment. In an agent-based deployment, an Azure DevOps agent is installed on every machine that the application will be installed on. Next, these agents must be grouped into deployment groups. Once this is done, a deployment group job can be added to the release.

This is very similar to an agent job, except for one thing. In an agent job, the tasks in the job will run on one of the agents against the target machine. In a deployment group job, all of the tasks will run on all of the agents in the release group on the target machines. This difference between both approaches can be seen in the following diagram:

When using this approach, it is necessary to have agents on the machines that the application needs to be deployed to. These agents listen to Azure DevOps and whenever a new release is requested, they retrieve the work and execute it on the local machine.