Introduzione

Il ciclo di vita del software, in informatica, e in particolare nell'ingegneria del software, si riferisce al modo in cui una metodologia di sviluppo scompone l’attività di realizzazione di prodotti software in sottoattività fra loro coordinate. Il risultato finale è il prodotto stesso e tutta la documentazione ad esso associata, fasi tipiche includono lo studio o l'analisi, la progettazione, la realizzazione, il collaudo, la messa a punto, la manutenzione e l’estensione; il tutto ad opera di uno o più sviluppatori software.
Lo sviluppo software è un processo molto complesso e vasto in tutte le sue fasi, tanto da richiedere, a volte, numerosi sviluppatori software per il completamento in tempi ragionevoli o prefissati. Talvolta, un progetto software è portato avanti da una community di utenti distribuita in rete attiva attraverso newsgroup, come accade ad esempio per diverse distribuzioni GNU/Linux; quando poi da un progetto software se ne sviluppa un altro, a partire dallo stesso tipo di programma, ma portato avanti da un’altra community, si parla di fork.

Wikipedia - Ciclo di vita del software

 

 

AzureDevOps: le funzionalità

Microsoft ha da poco rilasciato uno strumento che racchiude in toto quanto appena citato: Azure DevOps. Grazie ad esso è possibile gestire le diverse fasi mediante le funzionalità offerte e suddivisibili in cinque sottoprodotti:

- Azure Pipelines: consente di produrre soluzioni testate in tempi brevi mediante l’utilizzo di pratiche di CI/CD cross platforms e cross languages;
- Azure Boards: consente agli utenti di conoscere lo stato, pianificare e discutere del lavoro fra i vari team coinvolti nello sviluppo;
- Azure Repos: offre il versioning del software e, se usato in combinazione con Git, offre la possibilità di realizzare codice migliore mediante pratiche di pull requests e code reviews;
- Azure Test Plans: offre una piattaforma per l’esecuzione di test manuali;
- Azure Artifacts: consente la creazione e la condivisione di artefatti creati medianti processi di CI.

Tutto questo viene offerto gratuitamente per progetti open source, per tutte le altre casistiche di seguito il pricing completo. Vista la vastità degli argomenti tecnici trattabili su questa piattaforma, sarebbe impensabile esplicitare tutto in un solo articolo per cui abbiamo deciso di creare una serie di articoli.

In questo primo articolo tratteremo una delle suddette funzionalità: Azure Pipelines.

Per il proseguo di questo articolo diamo per assunta la conoscenza di base della nuova dashboard di Azure DevOps e la parte di inizializzazione e configurazione di un nuovo progetto.

Introduzione alla Continuos Integration

Ma quali sono i principali step?

Essenzialmente una pipeline di build si può così suddividere:

1. download sorgenti;
2. restore di eventuali dipendenze;
3. build dei sorgenti;
4. esecuzione di eventuali test;
5. pubblicazione di eventuali artefatti;

Creazione di una pipeline di build con Azure Pipelines

La creazione di una pipeline di build in Azure Pipelines può avvenire in due modi:
- visual designer;
- file azure-pipelines.yml

Fra le due modalità sopra esposte è preferibile utilizzare un’esecuzione della pipeline mediante file yml ma in questo articolo tratteremo una configurazione mediante visual designer in quanto di più facile esplicazione.

La motivazione per la quale è preferibile la creazione mediante file è dovuta al fatto che questa vive insieme al codice e quindi può essere modellata contestualmente alla naturale evoluzione di esso e versionata.

Una volta selezionata la modalità visuale sarà nostra premura scegliere il repository ed il branch sul quale avviare la pipeline.

A questo punto ci verrà presentata l’effettiva interfaccia per la definizione degli step, per semplicità abbiamo selezionato un template fra quelli disponibili, ASP.NET Core (.NET Framework).

Questo template utilizza il pool Hosted VS2017 disponibile per default, la lista completa degli agent è disponibile qua Agent pools.
In Azure Pipelines ogni pools dispone di una propria coda di esecuzione che processa sequenzialmente ogni pipeline lanciata, sia che questa sia stata lanciata manualmente o che sia stata triggerata alla ricezione di un commit sul ramo precedentemente selezionato.
È chiaramente possibile creare ulteriori agent e persino ospitarli in macchine on-premises.

Sì, ma questo template cosa fa?

In prima istanza definisce il gestore delle dipendenze, in questo caso NuGet.
Successivamente procede al restore delle dipendenze ed alla build della soluzione. In seguito esegue i test unitari per tutti quei progetti denominati con il pattern *.Tests.csproj ed infine procede a pubblicare l’artefatto prodotto sulla directory drop utilizzando il servizio Azure Artifacts.

Qui nel dettaglio quanto descritto sopra. 

 

Alla fine di ogni build si potranno visionare i log prodotti da ogni singolo step eseguito durante la pipeline mediante i quali sarà possibile prendere visione di eventuali rossi.

Infine si potrà visionare tutti i work items ed eventuali pull requests che hanno riguardato la specifica versione del codice sul quale è stata eseguita la pipeline.

 

Conclusioni

In questo articolo abbiamo trattato una minima parte della piattaforma Azure DevOps, nei prossimi articoli procederemo a trattare gli altri prodotti messi a disposizione degli sviluppatori, stay tuned!