In questi anni, in Blexin abbiamo realizzato un CMS molto modulare e ad alte prestazioni, che consente di semplificare lo sviluppo di portali web in maniera indipendente dallo storage utilizzato per la persistenza dei dati. WebRight, questo è il suo nome, utilizza al suo interno diversi plugin a seconda delle funzionalità che servono nel portale finale, e la parte di astrazione dello storage viene resa possibile grazie a Raptor, altro framework sempre sviluppato in Blexin.

Durante lo sviluppo di questi prodotti, abbiamo più volte sentito l’esigenza di avere un buon modo per versionare le dipendenze tra i plugin, onde evitare di ritrovarci nel classico problema di dependency hell (a questo link potete trovare maggiori dettagli). In questo articolo, vorrei raccontarvi come abbiamo cominciato a versionare le dipendenze nei nostri framework. Nei prossimi, invece, vedremo le diverse pratiche che abbiamo poi adottato per raggiungere quello che ad oggi è il modo in cui versionamo il nostro software in azienda.

Stabilire un processo di versionamento

Quando si sviluppa software, un topic sempre abbastanza caldo è quello del versionamento. Generalmente, il versionamento del software ha molto senso quando distribuiamo librerie o esponiamo API. Ci può capitare, però, di estendere il concetto a tutti i nostri software, sebbene in alcuni casi (ad esempio una applicazione web), può avere poco senso visto che il principale utilizzatore, il nostro customer, non ha interesse sui numeri di versione. Durante lo sviluppo dei framework WebRight e Raptor, abbiamo sin da subito stabilito un modo per poter versionare le release dei nostri plugin e soprattutto delle varie librerie condivise fra i due framework stessi. Siamo partiti nel definire un processo per farlo: ci servivano, nello specifico, una serie di regole per generare i numeri di versione. Una volta stabilite e condivise, abbiamo cominciato a versionare le nostre librerie usando l’attributo AssemblyVersion nella classe AssemblyInfo.cs:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Revision and Build Numbers 
// by using the '*' as shown below:
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.*")]

Abbiamo scelto di utilizzare le seguenti regole:

• Major per noi è un numero che viene incrementato in caso di una breaking change, qualcosa non compatibile con le precedenti versioni della libreria;
• Minor per noi è una nuova feature che non rompe con le precedenti versioni o è un bugfix.

In questo contesto, l’asterisco consente di generare i valori di Build e Revision in maniera automatica, svincolandoci dall’incarico. Siamo partiti impostando manualmente questi valori nella classe e, anche se questa cosa può far storcere per un attimo il naso, occorre capire che non c’è nulla di male a farlo, a patto che lo si faccia con criterio e con un processo ben definito. Naturalmente, una volta stabilito un processo, sarebbe banale non automatizzarlo con una build pipeline, per trarne tutti i benefici del caso.

Come versionare un pacchetto NuGet

Adottato questo processo, è stato poi semplice realizzare e condividere i pacchetti NuGet all’interno del team. Si può ad esempio utilizzare NuGet Package Explorer, oppure la CLI di NuGet per semplificare l’intera procedura. Dopo aver aggiunto al file AssemblyInfo.cs tutti i dettagli relativi al nostro progetto e aver compilato quest’ultimo, possiamo generare un file nuspec nella cartella dello stesso usando la CLI con il seguente comando:

nuget spec

Una volta creato il nuspec, possiamo eseguire il seguente comando per creare il nostro pacchetto NuGet:

nuget pack nome_progetto.csproj -IncludeReferencedProjects

In particolare, il flag -IncludeReferencedProjects ci consente di includere tutte le dipendenze nel pacchetto finale. Tramite il NuGet Package Explorer, possiamo anche aprire il pacchetto NuGet generato per verificarne il contenuto:

Una volta terminata la fase di definizione, siamo pronti per condividere il nostro pacchetto su un feed NuGet.

Pushare un pacchetto su NuGet

Se usiamo Azure DevOps possiamo creare facilmente un feed NuGet all’interno della sezione Artifacts.

Una volta creato il feed, occorre generare un token per collegarsi ed effettuare il push dei pacchetti nelle impostazioni del proprio account. Nella pagina di connessione al feed, è possibile trovare tutte le istruzioni e anche i comandi necessari per effettuare il push:

Non ci resta che caricare il pacchetto usando il comando:

NuGet push -Source "<Source>" -ApyKey <Key> nome_package.nupkg

Quando abbiamo caricato il nostro pacchetto, possiamo vedere le diverse versioni disponibili:

Infine, possiamo agganciarci al feed in Visual Studio andando in Tools -> NuGet Package Manager -> Package Manager Settings e ora, quando cerchiamo un pacchetto, visualizzeremo sia i pacchetti provenienti dal nostro feed che da altri e li possiamo importare nei nostri progetti.

Qual è il prossimo passo?

In questo articolo abbiamo visto il primo passo che abbiamo fatto in azienda per l’adozione del versionamento per i nostri pacchetti NuGet. Nel prossimo articolo, vedremo come l’uso di git e in particolare di GitFlow ci hanno aiutato a semplificare questo processo.