Aumentando il numero di processi automatizzati all'interno della nostra organizzazione aziendale, aumentano anche il numero di pipeline e, di conseguenza di agent, che ci troviamo ad utilizzare. Questo comporta che possiamo ritrovarci nella situazione in cui raggiungiamo facilmente il limite di agent che possono girare in parallelo, iniziando a creare una coda di job che, però, di default hanno tutti la stessa priorità e, quindi, vengono eseguiti in modalità FIFO. Tuttavia, sappiamo bene che una release urgente può avere una priorità più alta rispetto ad una build triggerata da una pull request appena creata e, pertanto, potrebbe aver senso dover impostare una priorità diversa. In questo caso, la priorità è modificabile direttamente sulla pipeline stessa, tramite il comando "Run Next" e solo nel caso in cui si sia nel ruolo di admin:

In altri casi, tuttavia, è comunque bene iniziare a pensare a come ristrutturare le pipeline più lunghe e articolate per identificare i passaggi "obbligatori" da quelli "opzionali". Supponendo il caso tipico in cui ad ogni change viene creata una infrastruttura ad-hoc, deployate le API, eseguiti i test e distrutta l'infrastruttura, capiamo immediatamente che la distruzione dell'infrastruttura è un di cui che non ci interessa ai fini di testare le change proposte dalla pull request. In questo caso, la parte "obbligatoria" riguardante i test rimarrà integrata nella pipeline "principale" invocata dalla PR stessa, mentre la distruzione dell'infrastruttura può essere invocata separatamente (in un'altra pipeline) e con una priorità più bassa del normale: l'importante è che risparmiamo sui costi e rendiamo l'ambiente pulito e riutilizzabile, ma non ci interessa se viene fatto immediatamente oppure dopo qualche minuto di "ritardo", poichè il processo, di fatto, rimarrà invariato.

Continuando con lo scenario preso in esempio, non ci rimane altro che sostituire il "job" (o lo stage) che si occupa nella pipeline della distruzione della infrastruttura, con una chiamata all'API di Azure DevOps responsabile per mettere in coda la build pipeline che farà la stessa cosa, ma separatamente. Prima di tutto, prepariamo l'endpoint:

$uri = "https://dev.azure.com/$env:ORGANIZATION/$env:TEAM_PROJECT/_apis/build/builds?api-version=6.0"

Quindi impostiamo il body della chiamata, indicando la pipeline che vogliamo invocare:

$body = @{
    priority = "low"
    sourceBranch = "refs/heads/main"
    definition = @{
        id = 1234
    }
} | ConvertTo-Json -Compress

Oltre a dichiarare i parametri necessari all'incodamento della pipeline (come il nome del branch per le pipeline YAML e la definizione della build), andiamo a specificare la priority. Impostando il valore low, come nel caso previsto dall'esempio, la build che verrà lanciata starà in fondo alla coda per più tempo rispetto al normale, per fare in modo che altre build più prioritarie, ad esempio, abbiano la precedenza nell'esecuzione. A questo punto, non ci resta che invocare la build definition tramite le REST API, come ultimo step:

$build = Invoke-RestMethod -Uri $uri -Method POST -Headers @{Authorization=("Bearer {0}" -f $env:SYSTEM_ACCESSTOKEN); "content-type" = "application/json"} -Body $body
Write-Host "Queued build: https://dev.azure.com/$env:ORGANIZATION/$env:TEAM_PROJECT/_build/results?buildId=$($build.id)"

In questo modo otteniamo comunque lo stesso comportamento (il processo di per sè rimane invariato), ma demandiamo l'ultimo stadio ad una esecuzione futura, così da ridurre i tempi sulla pipeline "principale" - che deve solo verificare le change - e di conseguenza le PR possono essere mergiate più rapidamente, senza perdita di qualità.

E' bene specificare che l'impostazione della priorità tramite REST API può essere fatta solo al momento dell'incodamento e non a pipeline già avviata. In quel caso, si può cambiare la priorità tramite il pulsante apposito "Run Next" come identificato in precedenza.