La build YAML

Tra le varie novità di VSTS / Azure Dev Ops, sicuramente la build YAML merita un posto particolare. Sicuramente questa modalità di definire la build diventerà nel futuro la preferita, infatti nell’ultimo update è stata introdotta una nuova funzionalità che permette di creare una build YAML con un semplice wizard e che tra l’altro fa si che la build YAML venga consigliata di default.

image

Il vantaggio principale a mio avviso della definzione dell’integrazione continua nel codice si ha con Git, dove la build segue la branch e quindi viene versionata assieme ai sorgenti. In ottica Dev Ops il concetto di build è fondamentale, perchè il suo scopo è rendere ripetibile la generazione dei pacchetti di installazione, fornire le metriche, validare la qualità delle pull request e quant’altro.

La definizione della build nel codice aiuta a rendere autoconsistente il progetto, spostando il repository tra Azure Dev Ops e GitHub o tra vari account, si ha il vantaggio di avere sempre l’integrazione continua configurata con il codice stesso

Il classico scenario è quello in cui dovete modificare la build per eseguire un nuovo script PowerShell, oppure eseguire la build di una solution nuova. Con il motore standard avete un’unica definizione per tutte le branch, per cui dovete giocare di esecuzione condizionale, facendo si che alcuni task vengano eseguiti solamente se è presente un file su disco etc. Con la build YAML questo problema non esiste più, se in una branch avete una nuova solution, basta modificare il file della build ed il task per compilare la nuova solution sarà presente solamente in quella specifica branch.

Avere la build versionata per branch rende molto semplice evolvere la continuous integration assieme al vostro codice

Il secondo vantaggio è quello di poter avere un reale ambiente di test per le modifiche delle build. Con lo scenario tradizionale potete salvare la build come draft, testarla, e poi promuoverla, ma con una buidl YAML potete avere quante branch volete per tutte le modifiche che volete fare alle build. In pratica è come avere infinite Draft.

Un altro vantaggio è avere la storia completa di come è evoluta la build nel source control, poter effettuare un facile diff per capire cosa è cambiato e poter ripristinare velocemente una vecchia versione o fare un merge tra versioni. Il poter fare un rollback sulla history della definizione è una funzionalità decisamente comoda.

Dato che la build è un file, è chiaramente facilissimo creare copie della build con lievi modifiche, ed è veramente facile spostare la definizione di buidl da un progetto ad un altro (la maggior parte delle volte quando iniziate un progetto avete una serie di task standard, a questo punto basta copiare il file di build da una build preesistente ed il gioco è fatto)

Insomma, se dovete creare una nuova pipeline di build in Azure Dev Ops, vi suggerisco di inizare a guardare la build YAML, perché sicuramente si rivelerà una scelta vantaggiosa.

Gian MAria.

Comments are closed.