Le pipeline che più spesso ci troviamo ad eseguire sono quelle che coinvolgono il processo di continuous integration dei progetti. Questo significa che eseguiamo gli step di restore delle dipendenze (indipendentemente che esse siano di NuGet, npm o altro) e quindi ci troveremo a "compilare" il progetto di riferimento (tramite msbuild o npm build), potenzialmente decine (o centinaia) di volte al giorno, poichè le pipeline verranno triggerate ad ogni commit/push sul repository, in base alla configurazione scelta.
E' molto importante, quindi, prevedere un meccanismo di versioning. Questo non solo aiuterà a produrre degli artefatti che potranno quindi essere distribuiti automaticamente con un numero di versione che viene incrementato automaticamente ma, in aggiunta, quando ci sono tante build in esecuzione aumenta anche la leggibilità dei log.
Il versioning è un tema piuttosto complesso e che andrebbe affrontato nello specifico in ogni progetto: di fatti, c'è chi preferisce avere estensioni dei progetti in Visual Studio, piuttosto che un sistema centrale lato server che calcola il numero automaticamente all'esecuzione delle pipeline stesse. A prescindere da pro/contro di ciascuna soluzione, affrontiamo oggi la seconda opzione. Per questo tema ci può venire in aiuto GitVersion, una estensione gratuita di Azure DevOps e distribuita anche in modo open source (alla fine è un semplice eseguibile da installare sulla macchina che contiene il repository) che, semplicemente leggendo lo stato del repository corrente, è in grado di calcolare un numero di versione automaticamente secondo determinate convenzioni:
In base al nome del branch, dei tag, del numero di commit fatti e del contesto (es. Pull Request piuttosto di CI), questo sistema calcolerà un numero di versione appropriato e lo esporrà come variabile d'ambiente a livello di macchina:
# Install GitVersion using GitTools extension - task: gitversion/setup@0 displayName: Install GitVersion inputs: versionSpec: '5.x' # Detects the version using GitTools - task: gitversion/execute@0 displayName: Detect version timeoutInMinutes: 2 continueOnError: true
A livello di pipeline, come possiamo vedere, è piuttosto semplice includere gli step necessari al calcolo del numero di versione. E' bene specificare che, tuttavia, il sistema in ambienti molto complessi ha bisogno di una configurazione ad-hoc (che possiamo passare in input o tramite un file GitVersion.yml), altrimenti potrebbe andare in un loop infinito, per questo è sempre bene prevedere comunque un fallback valido per fare in modo che la pipeline possa procedere senza problemi.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Evitare (o ridurre) il repo-jacking sulle GitHub Actions
Eseguire i worklow di GitHub su runner potenziati
Creare una custom property in GitHub
Esportare ed analizzare le issue di GitHub con la CLI e GraphQL
Estrarre dati randomici da una lista di oggetti in C#
Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
Eseguire una ricerca avanzata per recuperare le issue di GitHub
Utilizzare un service principal per accedere a Azure Container Registry
Eseguire le GitHub Actions offline
Garantire la provenienza e l'integrità degli artefatti prodotti su GitHub