Ci sono alcuni scenari, come ad esempio lo sviluppo e la distribuzione di librerie, che richiedono che i test vengano eseguiti su diversi tipi di condizioni per assicurarci che la librerie siano sempre funzionanti. Questo è vero storicamente, ma si è ancor di più accentuato dall'introduzione di .NET Core in quanto il codice della libreria può girare non più solo su Windows, ma anche su altri sistemi operativi.
Per simulare quest'ultimo scenario, è vero che per quanto riguarda le pipeline possiamo utilizzare i template YAML. Questi infatti prevedono una sequenza di operazioni e possiamo anche fornire in input diversi tipi di parametri, fra cui l'agent con cui eseguire le operazioni. Tuttavia, Azure DevOps fornisce out-of-the-box una strategia, definita "a matrice", che permette di eseguire lo stesso flusso di codice in condizioni differenti.
strategy: matrix: linux: imageName: 'ubuntu-latest' mac: imageName: 'macos-10.14' windows: imageName: 'windows-latest' pool: vmImage: $(imageName) steps: - script: dotnet restore - script: dotnet build --configuration Debug --no-restore - script: dotnet test --configuration Debug - script: dotnet publish --configuration Release
Come si può vedere dall'esempio, ci è sufficiente specificare a livello di job la keyword strategy per spiegare all'agent che ci saranno diverse modalità di esecuzione. In questo caso, stiamo solamente andando a definire delle variabili e, queste, verranno usate nei passaggi successivi. Infatti, il parametro imageName prende un valore diverso rispetto alla configurazione della matrice e questo verrà riutilizzato come parametro del pool, facendo in modo che la pipeline venga eseguita in automatico non solo su un agent, ma addirittura su tre, mantenendo lo stesso processo di build e release definito in precedenza per buildare, ad esempio, solo con Windows.
Sebbene il job di default sia solamente uno, possiamo vedere come Azure DevOps all'avvio della pipeline schedulerà in automatico l'esecuzione su tutti gli agent specificati dalla matrice:
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Usare Refit e Polly in Blazor per creare client affidabili e fortemente tipizzati
Generare token per autenicarsi sulle API di GitHub
Verificare la provenienza di un commit tramite le GitHub Actions
Code scanning e advanced security con Azure DevOps
Effettuare chiamate con versioning da Blazor ad ASP.NET Core
Eseguire attività con Azure Container Jobs
Esportare ed analizzare le issue di GitHub con la CLI e GraphQL
Sfruttare i KeyedService in un'applicazione Blazor in .NET 8
Evitare la command injection in un workflow di GitHub
Copiare automaticamente le secret tra più repository di GitHub
Disabilitare automaticamente un workflow di GitHub (parte 2)
Utilizzare i primary constructor in C#
I più letti di oggi
- Miglioramenti nelle performance di Angular 16
- Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
- HTML5 con CSS e JavaScript
- Ottimizzazione dei block template in Angular 17
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!