Nelle grandi aziende ci sono sicuramente decine, se non centinaia, di progetti configurati all'interno di Azure DevOps. Quando si parla di incrementare (o perlomeno implementare) la sicurezza, soprattutto a livello di rete, spesso si ricorre all'integrazione di agent privati oltre a quelli hosted forniti da Microsoft stessa. Tuttavia, questi agent pool devono essere manutenuti e la complessità di manutenzione dipende dalla quantità di software e di configurazioni/versioni che devono essere disponibili.

Uno dei vantaggi dell'uso dei container, facendo un confronto con un ambiente web, ad esempio, consiste nel portarsi tutta l'infrastruttura e le dipendenze necessarie ad eseguire le applicazioni proprio all'interno del container stesso, così da non dover configurare un web server ad-hoc (la VM agent) e, ad esempio, fare hosting di applicazioni con diverse versioni di .NET installate side-by-side. La rimozione di uno dei container, inoltre, farebbe la pulizia di tutte queste dipendenze, lasciando la macchina fisica pulita e riutilizzabile per altri container/applicazioni.

Lo stesso concetto può essere quindi applicato anche per le pipeline di Azure DevOps. I container possono quindi essere deployati all'interno di un agent (sia hosted che self-hosted) e i vari task di processo possono girare all'interno di esso. Il vantaggio, come detto, è che le varie configurazioni sarebbero direttamente integrate con il container e la pipeline non deve preoccuparsi di installare software di terze parti e possiamo fare molta meno manutenzione sull'agent stesso (zero, se non abbiamo accesso come negli agent hosted).

Supponiamo, quindi, di avere N applicazioni che puntano ad N versioni diverse di .NET Core. Come detto, sul server non sarà necessario installare nulla, poichè sarà il container a servire le dipendenze necessarie all'esecuzione:

Lato pipeline, non dobbiamo fare altro che specificare su quale container eseguire la pipeline stessa:

pool:
  vmImage: 'ubuntu-latest'

container: mcr.microsoft.com/dotnet/core/sdk:5.0

steps:
- script: dotnet restore
- script: dotnet build -c release

La stessa identica pipeline (quindi riutilizzando un template, potenzialmente), può girare all'interno di un altro container che punta, però, ad una versione differente di .NET 5.
L'unica difficoltà, come possiamo intuire, consiste nel trovare l'immagine ad-hoc richiesta per eseguire la pipeline. In questo caso la scelta è stata semplice poichè abbiamo bisogno di un container Linux-based, contenente l'SDK di .NET 5.

Nei prossimi script vedremo come integrare anche container di terze parti per eventuali dipendenze con servizi custom o esterni.