Uno dei primi argomenti che dobbiamo affrontare, quando progettiamo una nuova pipeline, è la scelta dall'agent giusto. Infatti, non è detto che tutti gli step e gli automatismi che andremo a definire gireranno indifferentemente su tutti gli agent: potrebbe essere certamente uno scenario possible ma, talvolta, potremmo avere delle dipendenze da Windows (es. per compilare un'app .NET Framework), piuttosto che da macOS (es. per creare un'app per iOS).
L'impostazione dell'agent viene specificata tramite la property pool e può essere fatta globalmente su tutta la pipeline, per specificarne uno di default, piuttosto che per ogni stage o job, in modo più selettivo:
pool: vmImage: 'windows-latest'
Come si può intuire dal nome della property e dal codice di esempio, però, non stiamo specificando solo l'agent, ma direttamente tutto il pool. In questo caso, significa che prenderemo in considerazione il primo fra tutti gli agent disponibili (in base al livello di parallelismo) dal pool di macchine chiamato 'windows-latest' (ovvero le hosted VM di Microsoft con l'ultima versione di Windows).
Tuttavia, le hosted VM hanno software pre-installato da Microsoft e, quindi, potrebbero non servirci nel caso in cui ci fosse la necessità di software custom. In questo scenario, l'IT avrà configurato un pool di macchine self-hosted, che conterrà N macchine pronte ad essere utilizzate per eseguire la pipeline. Per supportare un pool self-hosted, dobbiamo modificare il codice precedente in:
pool: name: 'MyPool'
All'interno del pool di macchine, però, potrebbero esserci configurate VM Windows, Linux, macOS o altro ancora. Come anticipato, però, non è detto che la nostra pipeline possa girare ovunque e quindi abbiamo bisogno di impostare delle specifiche, ovvero le demands, per fare in modo che la pipeline cerchi il primo agent disponibile con le caratteristiche che noi ricerchiamo:
pool: name: 'MyPool' demands: - agent.os -equals Windows - Preview
La definizione delle capability può essere fatta direttamente dai setting di progetto/organizzazione, selezionando il pool e quindi i singoli agent:

Nell'esempio stiamo andando a filtrare tutte le macchine del pool MyPool, prendendo solo quelle che hanno Windows come sistema operativo e, tra queste, quelle che hanno anche la capability Preview (senza controllare il suo valore). Quando la pipeline partirà, in base alle opzioni di parallelismo impostate e in base al numero di macchine disponibili con la configurazione applicata, verrà associato un agent corrispondente alla richiesta e quindi saremo piuttosto sicuri che la pipeline girerà correttamente.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
DevSecOps applicato ad Azure DevOps
Cambiare automaticamente lo stato di un work item in una pipeline di Azure DevOps
Inizializzazione asincrona di un servizio allo startup di un'applicazione Blazor
Estensioni personalizzate per le pipeline di Azure DevOps e GitHub con .NET 5
Impostare l'auto-complete delle pull request in Azure DevOps
Aggiungere e rimuovere un tag ad un work item in una pipeline di Azure DevOps
Esecuzione condizionale delle pipeline in Azure DevOps
Formattare il log delle pipeline YAML di Azure DevOps
DevOps for any developer with GitHub
Modificare automaticamente la Wiki da una pipeline YAML con Azure DevOps
Elencare gli utenti loggati con Blazor Server
Hidden gems in Azure SQL that will make every developer want to use it!