Ogni pipeline che viene eseguita all'interno di Azure DevOps viene identificata da un numero univoco che la rappresenta e, solitamente, questo numero viene associato agli artifact pubblicati così da avere sempre un tracking completo end-to-end di tutto quello che viene usato nel ciclo di sviluppo, dal work item al prodotto finito.
Il numero utilizzato di default è così composto:
name: $(date:YYYY).$(date:MM).$(date:DD)$(rev:.r)
Il risultato finale è un numero di versione composto da quattro cifre che risulteranno in qualcosa di simile a "2019.12.11.0". L'ultima cifra, in particolare, è il numero di revisione della build utile, in questo caso, per identificare in modo univoco le build che vengono eseguite lo stesso giorno, rendendo il numero associato alla pipeline sempre crescente.
Questa tecnica sfrutta quello che è chiamato build counter, una funzionalità inizialmente riservata alle variabili di sistema e ora disponibile anche per le variabili custom definite da noi stessi. Consente di incrementare ad ogni run della pipeline un valore secondo un prefisso ed un seed predefinito:
variables:
version.MajorMinor: 1.0
version.Revision: $[counter(variables['Version.MajorMinor'], 0)]
steps:
- script: echo "Build number is $(version.MajorMinor).$(version.Revision)"
Nell'esempio abbiamo definito tramite la variabile MajorMinor il prefisso, mentre la seconda, lo zero, rappresenta il seeding, ovvero la base da cui partire per generare i numeri da incrementare. I numeri così generati dalle varie build saranno "1.0.0", "1.0.1", "1.0.2" e così via.
Supponendo che il prefisso cambi, ad esempio, da "1.0" a "2.0" per via una breaking change o di un rilascio di un nuovo prodotto, l'espressione counter rivaluterà sia il prefisso che il seeding, dato che verrà resettato. I numeri di build saranno quindi "1.0.2" e "2.0.0", "2.0.1" e così via.
E' importante tenere presente che l'espressione counter viene valutata solo una volta che la pipeline si è avviata e pertanto è necessario usare la sintassi $[ ... ] al posto della sintassi ${ ... } che viene valutata nella fase precedente di costruzione della build.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Fissare una versione dell'agent nelle pipeline di Azure DevOps
Creare una custom property in GitHub
Utilizzare Azure AI Studio per testare i modelli AI
Rendere i propri workflow e le GitHub Action utilizzate più sicure
Configurare il nome della run di un workflow di GitHub in base al contesto di esecuzione
Eliminare una project wiki di Azure DevOps
Utilizzare l'espressione if inline in una pipeline di Azure DevOps
Utilizzare gRPC su App Service di Azure
Migliorare la scalabilità delle Azure Function con il Flex Consumption
Recuperare App Service cancellati su Azure
Ordinare randomicamente una lista in C#
Utilizzare il nuovo modello GPT-4o con Azure OpenAI
I più letti di oggi
- a #RealCodeConf4 il 25 maggio a Firenze parleremo di #silverlight4. iscrizioni gratis su http://u.aspitalia.com/g9
- #HTML5 schema per avere l'intellisense su #VS2008 (anche express) http://u.aspitalia.com/ed
- Parallelizzare le chiamate HTTP con async/await e le Promise in JavaScript
- Rendere sicuro l'endpoint di HealthCheck in ASP.NET Core
- prime app per #wp7summer. vuoi fare strada con #wp7? 5 app e partecipi alla nostra nuova competition: http://aspitalia.com/yu #wp7dev
- disponibile #azure sdk 2.1, con supporto a #vs13 e nuovi tool per #vs12: https://aspit.co/ans