Prevent race condition in Azure DevOps continuous deployment

Often we would face a race condition in Azure DevOps deployment pipelines when multiple pipelines or multiple instances of the same pipeline try to deploy to the same target.

In most cases, we want only the latest deployment if the changes are continuously integerated into the same branch

Let's see how to setup Azure DevOps cd pipelines to deploy only the latest run of the pipeline when multiple runs are queued at the same time.

Create Environments:

Environments represent a collection of resources that can be targetted during a deployment. examples are Dev,Test,Prod e.t.c.

The environment is a logical target of a deployment and can be accessed via the following path

Pipelines → Environments.

Let's create three environments Dev, Test and Prod by following the instuctions

here.

Connect pipelines to the environment:

We need to modify the pipeline to associate with the environment.

perform the following:

• In the YAMl pipeline "environment: Dev" has to be added.
• Environment needs a special type of job called a "deployment job"
• the syntax will look similar to the below-given example

trigger:
- dev

pool:
  vmImage: ubuntu-latest

stages:

- stage: Build
  jobs:
  - job:
    displayName: Build the application
    steps:
    - script: |
        echo your build steps here...

- stage: Deploy
  dependsOn:
  - Build
  jobs:
  - deployment:
    displayName: Dev deploy
    environment: Dev
    strategy:
     runOnce:
       deploy:
         steps:
           - script: echo Deploying to Dev environment
             displayName: 'Dev deployment'

For the first-time deployment, the deploy stage will need permission to access the Environment Dev.

Please provide the permissions.

Create exclusive lock check:

Lets assume that there are three successive changes in the dev branch , we will see three runs in the dev pipeline but we might need only the latest.

add exclusive lock check in the Dev environment.

we will set the pipeline to deploy only the latest and cancel the older runs.

add the lockBehavior: runLatest at the pipeline level or on the stage level based on your needs.

trigger:
- dev

pool:
  vmImage: ubuntu-latest

lockBehavior: runLatest
stages:

- stage: Build
  jobs:
  - job:
    displayName: Build the application
    steps:
    - script: |
        echo your build steps here...

- stage: Deploy
  dependsOn:
  - Build
  jobs:
  - deployment:
    displayName: Dev deploy
    environment: Dev
    strategy:
     runOnce:
       deploy:
         steps:
           - script: echo Deploying to Dev environment
             displayName: 'Dev deployment'

From now on, if multiple pipelines try to deploy to the same target then the older runs will be autocancelled and only the latest will proceed to deploy.

Summary:

Multiple pipelines trying to deploy to the same target at the same time create inefficiencies but the good news is that it can be handled well by using exclusive lock checks.

Thanks for reading, Goodbye until next week!