Why do you specify a pool in a deployment job in Azure Pipelines?

Question

I find it hard to grasp the concept of deployment jobs and environments in Azure Pipelines. From what I understand, a deployment job is a sequence of steps to deploy your application to a specific environment, hence the environment field.

If so, why is there also a pool definition for agent pool for that job definition?

EDIT

What bothers me is that, from what I understand, an Environment is a collection of resources that you can run your application on. So you'll define some for dev, some for stage, prod, etc. So you want to run the job on these targets. So why do we need to specify an agent pool to run the deployment job on? Shouldn't it run on the resources that belong to the specified environment?

EDIT

Take this pipeline definition for example:

jobs:
  # Track deployments on the environment.
- deployment: DeployWeb
  displayName: deploy Web App
  pool:
    vmImage: 'Ubuntu-16.04'
  # Creates an environment if it doesn't exist.
  environment: 
     name: 'Stage'
     resourceType: VirtualMachine
  strategy:
    # Default deployment strategy, more coming...
    runOnce:
      preDeploy:
        steps:
        - script: echo "Hello"
      deploy:
        steps:
        - checkout: self 
        - script: echo my first deployment

I have an environment called "Stage" with one virtual machine on it.

When I run it, I can see both jobs run on my VM

The agent pool specified is NOT USED at all.

However, if I target another environment with no machines on it, it will run on Azure Pipelines vm

Answer 1

Yes this is confusing and you are right. I think they have made this a "feature" to cater for scenarios where you want to box deployments under "environments" but you can't actually run the deployment logic in the environment itself because it doesn't have any resources on which logic can be run.

Imagine this scenario, you have an FTP site for staging, and another for prod. The FTP site is provided by a thrid party hosting provider so you can't jump on and install a devops agent, you just get the FTP access credentials from them.

You want to set up a CI/CD pipeline and use a deployment job to deploy your site to "Staging" and "Prod" via FTP.

With this "Feature" you can run your FTP deployment job to deploy to "Staging" and "Prod" and the job can run on an agent pool agent and run some FTP task to deploy the files to the coorrect FTP site.

Now you can look at the environment page and have a better understanding over the deployment history of your app for those two environments, evenn though they have no resources.

Those saying that an empty environment (i.e no resources) is meaningless are not really seeming to understand the feature as a whole because there is some value in being able to cater for this scenario, all being it is failry limited (at present) as I have outlined.

However what is confusing about this "feature" is it is not clear / explicit over where the job logic will run when looking at the yaml - for example as you said, if you set the agent pool you would expect the job logic to run on that agent, but if the env has VM resources it doesn't - it gets ignored. This is a poor design imho. It would be better if microsoft made it so that if you set the pool the job ran on that agent pool regardless, if you wanted it to run on the resources in the environment, you could just omit the pool. If you don't specify a pool and the env has no resources the job could either fail telling yoou to specify a pool or register some resources, or alternatively the job could run on a default pool provided by microsoft if that is the typical behaviour.