Quando si eseguono dei processi automatici, dobbiamo dare per scontato che tutto l'automatismo vada a buon fine e, che nel caso qualcosa vada storto, dobbiamo assicurarci di gestire in modo appropriato gli errori che si verificano. Parte di questi errori, tuttavia, potrebbero essere dovuti a problemi transienti, che non dipendono direttamente dalla pipeline.

Di fatto, semplicemente riavviando il processo, potrebbero essere risolti senza dover toccare una riga di codice. Potrebbe essere questo il caso quando abbiamo il network di mezzo, che sia per scaricare un pacchetto di NuGet, che sia per chiamare le API di Azure DevOps, o altro, come per esempio l'esecuzione di test case.

Proprio per questi failure "temporanei", le pipeline non possono essere strutturati per capire che cosa succede ed agire di conseguenza. Microsoft, però, ha aggiunto il supporto ad un nuovo tag per permettere il retry automatico di un intero task/step:

- task: <nome>
  retryCountOnTaskFailure: <numero-retry>

Semplicemente impostando quella proprietà retryCountOnTaskFailure, possiamo chiedere alla pipeline di Azure DevOps di riprovare per un numero N di volte che definiamo a livello di business. Se dopo N volte il task fallisce in maniera consistente, allora l'errore è probabile che sia concreto e, quindi, dovremo gestirlo come tale, ad esempio agganciando al seguito un altro task che viene eseguito solo in condizione failed() sul precedente.

- script: echo 'Hello!'

- script: echo 'Triggered only on failure'
  condition: failed() # verrà eseguito solo quando il precedente fallisce

Chiaramente è bene prestare attenzione all'uso di retryCountOnTaskFailure: se cerchiamo di eseguire uno script dove in sequenza dobbiamo eseguire le chiamate agli endpoint A e B, ma solo la seconda chiamata fallisce, al secondo tentativo potrebbe fallire la chiamata ad A perchè al primo giro questa si è completata correttamente. Proprio per questo motivo è bene pensare ad una buona architettura per fare ogni step idempotente.