Quando lavoriamo con Azure DevOps, quasi sicuramente avremo a disposizione ben più di un agent per eseguire le nostre pipeline. Questo significa che, se abbiamo due o più repository, questi possono lanciare delle pipeline di build/deploy in contemporanea su due agent diversi ed isolati fra di loro, così da ottimizzare i tempi. Lo stesso può avvenire quando il trigger è sul commit di un branch e vengono effettuati più push, quindi rischiamo di avere più pipeline che partono in contemporanea.

Sebbene questo sia un caso desiderato la maggior parte delle volte, proprio per ottimizzare i tempi di esecuzione e per dare un feedback il prima possibile ai developer, talvolta può risultare problematico. Pensiamo ad esempio quando dobbiamo fare un deploy in un ambiente: avere due pubblicazioni in produzione in contemporanea non ci garantisce che la pipeline lanciata un secondo dopo la prima (e quindi l'ultima versione), sia effettivamente l'ultima versione che finisce nell'ambiente di produzione. Perciò dobbiamo valutare l'uso di lock per assicurarci che, almeno i passaggi più critici delle pipeline, vengano eseguiti per forza di cose in sequenza.

Il primo passaggio da completare riguarda la creazione di un environment in Azure DevOps con un lock associato:

Dopodichè possiamo creare una pipeline YAML in questo modo:

trigger:
- main

pool:
  vmImage: ubuntu-latest

lockBehavior: sequential 

stages:
- stage: Stage
  jobs:
  - deployment: Deploy
    environment: my-env
    strategy:
      runOnce:
        deploy:
          steps:
          - bash: echo "hello world"

Per prima cosa abbiamo inserito l'environment appena creato come risorsa del job che si occuperà di fare il deployment, in modo che questo possa valutare tutte le condizioni impostate (il lock, ma anche altre limitazioni). Nella root della pipeline abbiamo invece impostato in quale modalità il lock deve poter essere utilizzato e in questo caso il valore sequential indica proprio che verrà eseguito una sola run alla volta di questo job, mentre tutte le altre, triggerate assieme, verranno messe in coda per ordine esatto di esecuzione, garantendoci il fatto che l'ultima arrivata sarà l'ultima ad essere eseguita.