Era il lontano 2019 quando abbiamo parlato su questo canale per la prima volta delle pipeline di Azure DevOps dedicate alla parte di release management (https://www.dopsitalia.com/articoli/DevOps/intro-azure-devops-rm.aspx). Da allora, sono cambiate tante cose, sia dal punto di vista tecnologico, in cui le applicazioni si sono evolute e si parla sempre di più di microservizi, sia dal punto di vista della piattaforma Azure DevOps che ha introdotto sempre concetti nuovi per migliorare il processo di rilascio delle applicazioni, soprattutto nelle pipeline YAML.

Poiché le fasi di un rilascio sono più o meno definite, Azure DevOps ha introdotto il concetto di "deployment strategy" dedicata ai deployment jobs, che ci consente di definire task per ciascuna fase del rilascio. Vediamo un esempio:

name: 'Deployment strategy'

jobs:
- deployment: deploy
  environment: staging
  strategy:
    runOnce:
      preDeploy:
        steps:
        - script: echo "on pre-deploy"
      deploy:
        steps:
        - script: echo "on deploy"
      routeTraffic:
        steps:
        - script: echo "on route traffic"
      postRouteTraffic:
        steps:
        - script: echo "on post route traffic"
      on:
        failure:
          steps:
          - script: echo "on failure"
        success:
          steps:
          - script: echo "on success"
  pool:
    vmImage: ubuntu-latest

Partendo dal nodo del deployment, dobbiamo definire l'ambiente che verrà usato per il rilascio delle nostre applicazioni (ad esempio un ambiente custom, un cluster di kubernetes o un elenco di virtual machine). Dopodichè, dobbiamo specificare la tipologia di rilascio (runOnce è per un processo sequenziale semplice, quello più tipico) e quindi verranno inizializzate tutte le fasi in sequenza, dal pre-deploy al postRouteTraffic, invocato quando il deploy è completato, abbiamo rimandato gli utenti sul load balancer "corretto" e vogliamo verificare che tutto funzioni. Solo alla fine, quando tutte le fasi saranno completate, verrà effettuata una valutazione complessiva dello stato del deployment e verremo rimandati al passaggio di success o failure in base ai passaggi precedenti.

Ciascuna di queste fasi va a creare un job all'interno della pipeline, con il prefisso il nome del deployment job che abbiamo impostato noi, mentre il nome della fase sarà il suffisso (es. deploy_OnDeploy), in cui possiamo eseguire tutti i task del caso per poter effettuare un deploy nel modo più consono alle nostre esigenze. Qualora un passaggio non dovesse servirci, possiamo tranquillamente ometterlo e questo non creerà un job nella pipeline.

Lo step di failure viene chiamato solo nel momento in cui si è verificato un errore nei passaggi precedenti, quindi è anche nostra responsabilità fare tutte le considerazioni del caso per assicurarci nei vari step che l'applicazione sia stata rilasciata nel modo corretto e, eventualmente, far fallire intenzionalmente uno stage per poter entrare nella fase di "failure" e gestire, per esempio, un rollback per riportare lo stato desiderato.