Deployment jobs

• 5/2/2019
• 2 minutes to read
• Contributors
  • 

Azure Pipelines

In YAML pipeline, we recommend that you put your deployment steps in a deployment job. A deployment job is a special type of job that is used to deploy your app to an environment.

Overview

The advantages of using deployment jobs include:

• You can deploy to an environment, which includes benefits such as being able to see the history of what you've deployed. It's especially helpful to be able to trace deployments in those scenarios where multiple pipelines, stages and jobs are deploying to the same resource (deployment target).

• You can control how your deployment steps run.

  At the moment we offer only the runOnce strategy, which runs the deployment steps exactly once. The rolling strategy is on our roadmap to enable you to iteratively expand deployment steps.

Examples

Here's a very simple abstract example of a deployment job:

jobs:
- deployment: string
  pool:
    name: string
    demands: string | [ string ]
  environment: string
  strategy:
    runOnce:
      deploy:
        steps:
        - script: echo Hello!

The following example YAML snippet showcases the use of a deploy job -

jobs:
- deployment: DeployJob
  displayName: Deploy Job
  pool:
    vmImage: Ubuntu-16.04
  environment: staging
  strategy:
    runOnce:
      deploy:
        steps:
        - script: echo Hello

In the above example, with each run of this job, deployment history is recorded against the staging environment.

The following example snippet demonstrates how a pipeline can refer an environment and a resource within the same to be used as the target of a deployment job -

deployment: Deploy
  displayName: Deploy job
  pool:
    vmImage: 
  environment: staging.aks-cluster-namespace-1
  strategy:
    runOnce:
      deploy:
        steps:
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            namespace: staging
            manifests: |
              manifests/deployment.yml
              manifests/service.yml
            imagePullSecrets: |
              demo-secret
            containers: |
              fabrikam.azurecr.io/sample:test

The above approach has the following advantages -

1. More selective recording of deployment history on a specific resource within the environment as opposed to recording the history on all resources within the environment.
2. Referencing the Kubernetes type resource (aks-cluster-namespace-1 within environment staging in above example) results in automatic propagation of the service connection details (service connection backing the resource) for the steps authored under this deployment job. This is particularly useful in the cases where the same service connection value is to be set for multiple steps of the job.