Recentemente ho incontrato una creatura che non è ancora molto popolare nel mondo del DevOps, i pipeline di Azure DevOps. Ho subito avvertito la mancanza di istruzioni o articoli chiari sull'argomento; non so a cosa sia dovuto, ma Microsoft ha sicuramente del lavoro da fare per promuovere meglio questo strumento. Oggi costruiremo un pipeline per il testing automatizzato all'interno del cloud Azure.

Quindi, il compito:
Abbiamo un software che viene costruito utilizzando Azure DevOps, assemblato da un progetto su WIX. Se c'è interesse, scriverò anche di questo strumento. In effetti, si tratta di un metodo più ottimizzato per l'automazione della creazione di installer per Windows, che sostituisce il tradizionale InstallShield. Quindi, il nostro software si compila correttamente e genera un artefatto, un setup.exe, che installa l'applicazione nel sistema Windows. Dobbiamo installare questa applicazione in una macchina virtuale simile a quella di produzione, copiarvi i test automatizzati preparati dal team di testing, eseguirli e recuperare i risultati per valutare se il ramo è buono o cattivo, prima di eseguire il merge. Tutto come in GitLab, solo attraverso la ….

Come ambiente di virtualizzazione, dove eseguiremo i nostri test, utilizziamo, ovviamente, Azure DevTest Labs, una sorta di entità nelle sottoscrizioni Azure, creata appositamente per eseguire vari test a un costo ragionevole.

1. Integrazione sul lato cloud

Per iniziare, dobbiamo integrare i nostri DevTest Labs con Azure DevOps, per questo è necessario un Service Principal, in sostanza un'account di servizio che permette ai pipeline di accedere al cloud e di creare/eliminare risorse per sé.

Andiamo nella sottoscrizione e troviamo il servizio Azure Active Directory.

Troviamo Registrazioni App e clicchiamo su Nuova Registrazione, questo ci creerà il nostro service principal. Non entrerò nei dettagli su quali impostazioni scegliere durante la creazione, poiché potrebbe variare tra le diverse sottoscrizioni.

Ora dobbiamo concedere i diritti al nostro service principal. Per fare ciò, andiamo nelle sottoscrizioni, sull'icona con la chiave. Selezioniamo la nostra sottoscrizione.

Poi, in Controllo Accesso, clicchiamo su Assegnazione di Ruolo e cerchiamo nel campo di ricerca l'account che abbiamo appena creato. Diamo il ruolo di Collaboratore, questo è sufficiente.

Successivamente, torniamo al nostro Service Principal in Azure AD e apriamo le sue proprietà. Più tardi, avremo bisogno di tutti gli ID che ci sono, quindi salviamoli.

Così terminano le nostre impostazioni del portale e passiamo ad Azure DevOps.

2. Integrazione su Azure DevOps

Per prima cosa accediamo alle impostazioni del progetto e scegliamo Connessioni di servizio. Creiamo un nuovo elemento di tipo Azure Resource Manager.

Ora abbiamo bisogno di tutti gli ID che abbiamo annotato. Clicchiamo su usa la versione completa della finestra di dialogo della connessione di servizio. Inseriamo tutti i dati ricevuti da Service Principal. Facciamo clic su verifica e, se tutto è a posto, salviamo la connessione. Ora i nostri pipeline possono utilizzarlo per collegarsi al cloud.

3. Creazione del pipeline

Adesso passiamo alla parte più interessante, la creazione del pipeline. Apriamo il menu Pipelines-Builds

Ci troviamo di fronte al menu per creare una nuova build, che per impostazione predefinita cercherà di crearci un file YAML con la configurazione adatta. Rifiutiamo gentilmente l’offerta e scegliamo l'opzione classica. È ovvio il desiderio di Microsoft di rendere tutto più comprensibile e offrire la massima personalizzazione dei pipeline tramite YAML, ma la documentazione scarsa e la sostanziale inaffidabilità di molti moduli ci dicono che è ancora troppo presto per utilizzare questa funzionalità.

Tra la varietà di modelli, abbiamo bisogno di un semplice Empty Pipeline. Dopo la sua creazione, ci accoglie una finestra vuota di modifica, in cui passeremo abbastanza tempo.

Quindi, facciamo clic su + e accediamo a un negozio di moduli, da cui ci serviranno i seguenti componenti.

Prima di iniziare a configurare i task del pipeline, dobbiamo creare e aggiungere al progetto alcuni file. Questi saranno il Template ARM della nostra macchina virtuale, che genereremo in Azure DevTest Labs, uno script per recuperare l'IP della macchina dopo la sua creazione e, se desiderato, script dei nostri test o di ciò che vogliamo eseguire sull'host.

4. Generazione del Template ARM

Per creare la macchina virtuale, dobbiamo prima generare un template, un file JSON, che inseriremo nel codice del progetto affinché il pipeline possa leggerlo.

Ci dirigiamo al nostro lab e troviamo il menu Formulas (basi riutilizzabili), facciamo clic su crea nuovo.

Ci accoglierà un lungo elenco di immagini come base, la scelta della dimensione della macchina, tutto come quando creiamo una macchina virtuale. A questo punto non ci fermeremo, passeremo direttamente all'ultima voce delle proprietà della macchina, ovvero agli artefatti. Puoi utilizzare qualsiasi configurazione necessaria per il tuo ambiente. Ad esempio, aggiungo la macchina in dominio E aggiungo a questa un account di servizio come amministratore, in modo che il pipeline possa poi accedere a questa macchina con questo account. Tutto ciò può variare, ma per un test di codice riuscito abbiamo bisogno di un artefatto, di cui ci soffermeremo di più. Per installare l'ultima versione del software che stiamo testando sulla nostra macchina, utilizzeremo l'artefatto "Download Azure Pipelines Artifact and Run Script". Ricordate che all'inizio ho detto che da qualche parte viene generato un build con l'installer dell'applicazione? Ora dobbiamo dire alla macchina virtuale, o più precisamente al template, di andare a prendere questo artefatto. E non solo di prenderlo, ma anche di installarlo, per il quale riempiamo i campi speciali con l'indicazione del progetto, del nome del build e della chiave segreta. La chiave segreta, come in tutti i sistemi di questo tipo, viene generata nell'account, in questo caso in Azure DevOps e viene salvata in Secrets nel vostro laboratorio. Qui c'è una piccola avvertenza: in Secrets la salveremo, ma al template non cambia nulla, poiché verrà eseguito da un altro utente nell'ambito del pipeline; quindi dovremo inserire manualmente di nuovo la chiave segreta nel template.

Un altro artefatto che deve essere assolutamente incluso è "Configure WinRM", di cui avremo bisogno per l'accesso successivo alla macchina. Ci sono solo un parametro, hostname. Poiché non lo conosciamo in anticipo, useremo la variabile %COMPUTERNAME%.

Quindi abbiamo aggiunto tutti gli artefatti necessari, passiamo a ciò per cui siamo venuti qui. Otteniamo il Template ARM generato nella scheda Advanced della stessa finestra di creazione della formula.

Copia il contenuto della pagina nel file VMtemplate.json e posizionalo nella radice del progetto. Non ci serve altro cloud, torniamo al pipeline.

5. Configurazione del pipeline

Iniziamo con la cosa più importante e interessante, la creazione della macchina virtuale, per la quale abbiamo fatto tutte queste integrazioni e template. Nel punto Azure RM Subscription scegliamo la nostra connessione di servizio che abbiamo configurato nel punto 2. Poi dovrebbe apparire l'ambiente di laboratorio disponibile per noi. Successivamente, selezioniamo il json che abbiamo generato e definiamo alcune variabili obbligatorie. Il nome utente e la password della macchina possono essere impostati direttamente o tramite variabili, ma non sono del tutto sicuro che funzioni; qualsiasi cosa io scriva, non sono riuscito ad accedere alla macchina con queste credenziali. È importante dare un nome alla macchina che, per quanto possibile, sia sempre unico. A tal fine, utilizzo una variabile ambientale di build.

Poi configuriamo un altro aspetto non trascurabile. Dopo che la macchina è in funzione, dobbiamo in qualche modo conoscerne i parametri, e meglio se non siamo noi a doverlo fare, ma il pipeline. A questo scopo, creiamo uno script, ad esempio GetLabVMParams.ps1, e lo posizioniamo nella stessa cartella del progetto. Il testo dello script l'ho preso dal sito Microsoft, ma l'ho modificato un po' per il mio ambiente, poiché prendeva il PublicIP e il FQDN della macchina. Non ho né l'uno né l'altro, ma ho un PrivateIP che non è così semplice da ottenere, quindi ho aggiunto un pezzetto.

Param( [string] $labVmId)

$labVmComputeId = (Get-AzureRmResource -Id $labVmId).Properties.ComputeId

# Ottieni il nome del gruppo di risorse della VM di laboratorio
$labVmRgName = (Get-AzureRmResource -Id $labVmComputeId).ResourceGroupName

# Ottieni il nome della VM di laboratorio
$labVmName = (Get-AzureRmResource -Id $labVmId).Name

# Ottieni l'indirizzo IP pubblico della VM di laboratorio
# $labVMIpAddress = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).IpAddress

# Ottieni il FQDN della VM di laboratorio
# $labVMFqdn = (Get-AzureRmPublicIpAddress -ResourceGroupName $labVmRgName -Name $labVmName).DnsSettings.Fqdn

# Ottieni l'indirizzo IP privato della VM di laboratorio
$VmNetworkdetails= (((Get-AzureRmVM -ResourceGroupName $labVmRgName -Name $labVmName).NetworkProfile).NetworkInterfaces).Id
$nicname = $VmNetworkdetails.substring($VmNetworkdetails.LastIndexOf("/")+1)
$labVMnetwork = (Get-AzureRmNetworkInterface -Name $nicname -ResourceGroupName $labVmRgName)|Select-Object -ExpandProperty IPConfigurations 
$labVMIpAddress = $labVMnetwork.PrivateIpAddress

# Imposta una variabile labVmRgName per memorizzare il nome del gruppo di risorse della VM di laboratorio
Write-Host "##vso[task.setvariable variable=labVmRgName;]$labVmRgName"

# Imposta una variabile labVMIpAddress per memorizzare l'indirizzo IP della VM di laboratorio
Write-Host "##vso[task.setvariable variable=labVMIpAddress;]$labVMIpAddress"

# Imposta una variabile labVMFqdn per memorizzare il nome FQDN della VM di laboratorio
Write-Host "##vso[task.setvariable variable=labVMFqdn;]$labVMFqdn"

Write-Output $labVMIpAddress

Set-Item wsman:localhostclienttrustedhosts * -Force

Di tutto ciò che lo script legge, abbiamo bisogno solo della variabile labVMIpAddress. Magari a voi serve qualcos'altro, perciò non ho cancellato nulla e ho semplicemente commentato il resto.

Spiego anche l'ultima riga dello script; questa consente alla nostra macchina di build di accedere a qualsiasi host tramite WinRM.

Nella fase successiva avviamo il nostro fantastico script. Avrà bisogno della stessa connessione al cloud, una variabile di input con l'ID della macchina, che sarà già nota dal passo precedente. Come? Qui è importante menzionare una cosa meravigliosa chiamata Output Variables. Ogni passo può avere un elenco di variabili che vengono passate in seguito ai passi successivi del pipeline. Pertanto, per il nostro super script, questa variabile sarà labVMIpAddress, non dimenticate di specificarlo.

Poi faccio cose abbastanza semplici, che comunque possono variare da caso a caso. Eseguo uno script remoto con la creazione di una condivisione, nella quale caricherò poi i miei script.

New-Item “C:test" –type directory
New-SMBShare –Name “test” –Path “C:test”  –FullAccess everyone

Dal nome dei task è chiaro che poi copiamo un certo sample script sulla macchina e in un ulteriore passo lo eseguiamo. Come indirizzo della macchina remota ci sarà utile la nostra variabile $(labVMIpAddress). Poi utilizziamo il task "recuperare artefatto dalla condivisione" e copiamo i risultati dell'esecuzione dello script nella nostra ambiente di build, quindi con lo stesso task standard salviamo questi file nell'artefatto di build. Dopo che la macchina non ci serve più, come ultimo passo la distruggiamo. La principale difficoltà, come si vede dall'ampiezza dell'articolo, è integrarsi con il cloud e stabilire un contatto con la macchina virtuale che hai creato, poi puoi divertirti quanto vuoi.

Questo è il mio primo articolo, quindi non giudicate troppo severamente, i feedback sono benvenuti.

Fonte: habr.com