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
Evitare la command injection in un workflow di GitHub
Eseguire un metodo asincrono dopo il set di una proprietà in Blazor 8
Disabilitare automaticamente un workflow di GitHub (parte 2)
Generare token per autenicarsi sulle API di GitHub
Sostituire la GitHub Action di login su private registry
Eseguire una query su SQL Azure tramite un workflow di GitHub
Eseguire operazioni sui blob con Azure Storage Actions
Eseguire operazioni con timeout in React
Visualizzare le change sul plan di Terraform tramite le GitHub Actions
Sviluppare un'interfaccia utente in React con Tailwind CSS e Preline UI
Copiare automaticamente le secret tra più repository di GitHub