VSTS hosted agent vs. private agent

1
votes

What's the difference between using a hosted agent and private agent in terms of deployment?

Correct me if I'm wrong - a private agent is a service that's hosted privately, and continuously checks if there's a new build triggered for which build definition it's been configured to do, and then pulls the source code from VSTS and invokes MSBuild locally on that machine.

If there's a PowerShell post script to be executed in that build definition, it runs that as well - which can handle the actual deployment and so forth.

Perhaps there are more ways to handle deployment, but how would a hosted agent work?

For simplicity, let's just assume that an ASP.NET application should be deployed to IIS whenever a new build has been triggered.

1
asp.netiistfsazure-pipelines
You said "in terms of deployment" implying that you're concerned about Releases. But then you go onto mentioning build definitions, which implies it's Builds you care about. There's a difference. For most builds, it doesn't matter where they run so long as the necessary compilers are available. For releases, it may matter where the agent is run because you may need the agent to run inside of a network sitting behind NAT to deploy to a particular machine. – mason

1 Answers

7
votes

VSTS builds should be used to build your package and VSTS release management should be used to do the deployments. It is possible to do deployment tasks via the build as well, but a more controlled and recommended way is to use release management in VSTS for deployment purposes.

Hosted agent

There are four hosted agents you get for VSTS

  1. Hosted agent without Visual Studio 2017
  2. Hosted agent with Visual Studio 2017 support
  3. Agent on Linux
  4. Agent on Mac

These hosted agents can be used to do builds and deployments to servers which are publicly accessible from the agent. Let's say you want to deploy to Azure web applications, then you can use the hosted agent in VSTS release management to run the required deployment scripts or tasks.

But these hosted agents do not have "line of sight" to your local network. For example, your machines behind a corporate firewall are not exposed publicly. In such scenarios, a hosted agent cannot deploy to your machine, behind your corporate firewall, because the agent cannot see your machine.

Private agents

You can set up an agent for VSTS in your corporate domain, which can access VSTS via web, so it can listen to any deployment jobs. This private agent inside your firewall, has the "line of sight" to your machines inside the firewall, so the agent can do deployments to them.

Other scenarios for which you may need private agents for builds, is when you need some specific SDK availability which is not available on hosted agents. Let's say you are having a SharePoint 2013 based application. To build that, the build server needs to have SharePoint 2013 installed, which is not offered in hosted agents. You have to use a private agent to set up SharePoint 2013 to allow building the application based on SharePoint 2013.

Refer to here for more details.

Deployment groups

You can use deployment groups to do deployments to the machines inside your corporate domain firewall since you will be deploying private agents to each of the machines that requires a deployment to happen. Deployment groups are explained here.