Nello script precedente abbiamo introdotto il concetto delle pipeline che possono girare all'interno di un container. In questo modo, possiamo portare nell'agent tutte le dipendenze di terze parti che sono richieste alle pipeline stesse, senza che questo debba essere preventivamente configurato. L'agent risulterà, infatti, a tutti gli effetti pulito e riutilizzabile da qualsiasi altra pipeline.

Supponiamo però il caso in cui dobbiamo eseguire degli integration test. Questi, poichè si basano su una infrastruttura vera e propria, potrebbero avere bisogno di un database in cui salvare i dati. In uno scenario simile, possiamo sfruttare il concetto di service container per caricare un container di servizio side-by-side a quello in cui verrà eseguita la pipeline.

pool:
  vmImage: 'ubuntu-latest'

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

resources:
  containers:
  - container: sql
    image: mssql/server:2019-latest
    options: 'ACCEPT_EULA=Y SA_PASSWORD=yourStrong(!)Password'

services:
  sql: sql

steps:
- script: dotnet restore
- script: dotnet build -c release
  env:
    CONNECTIONSTRING: sql:1433

La pipeline è molto simile a quella che abbiamo visto la volta scorsa. Tuttavia, in questo caso facciamo uso del nodo resources per includere un ulteriore container (o una lista di essi) alla pipeline. Quando il processo verrà messo in esecuzione, verrà fatto il pull sia del container principale, ovvero di quello contenente l'SDK di .NET 5, sia del container di servizio contenente SQL Server 2019 (la cui configurazione può variare).

Grazie al nodo di services "esponiamo" effettivamente il container per fare in modo che questo sia "visibile" alla pipeline e utilizzabile da uno dei task contenenti nel job in esecuzione. Non solo, grazie al service possiamo creare un alias che identificherà in maniera univoca il container in esecuzione e che potrà essere utilizzato in seguito nella pipeline. In questo caso, il container è stato referenziato semplicemente passando il suo alias e la porta (di default sulla 1433 ma è personalizzabile tramite l'attributo port specificabile nel nodo container) come input di una variabile d'ambiente chiamata CONNECTIONSTRING. Questa variabile di per sè non significa nulla: è di fatto l'applicazione stessa che dovrà andare a leggere e recuperare il valore della variabile d'ambiente creata ed esposta dalla pipeline per fare in modo che possa salvare delle informazioni all'interno del SQL Server eseguito in container.