Costruisci Pipeline Azure DevOps per Template ARM nel Mondo Reale

Tutorial
DevOps

Quando cerchi online, troverai vari post di blog, documentazione e tutorial su Azure DevOps. Tutti questi elementi sono risorse preziose, ma raramente uno di essi ti guida attraverso uno scenario reale. Molti tralasciano l’aspetto della sicurezza, lasciando le password in chiaro per semplicità o un prodotto finale che in sostanza non fa nulla. Cambiamo questo.

In questo articolo/tutorial, imparerai passo dopo passo come creare una pipeline di rilascio di Azure DevOps che automatizza l’infrastruttura. Più specificamente, imparerai come utilizzare Azure DevOps per creare una pipeline di distribuzione continua per la fornitura di macchine virtuali di Azure.

Alla fine di questo progetto, avrai una pipeline di Azure completamente funzionante. Da un singolo commit di un repository GitHub, essa:

  • Creerà un gruppo di risorse temporaneo di Azure
  • Fornirà una VM di Azure tramite un modello ARM
  • Configurerà il suddetto modello ARM in una pipeline CI/CD
  • Alla modifica del modello, avvierà un test di convalida del modello
  • Effettuerà il rilascio del modello ARM su Azure
  • Testerà l’infrastruttura distribuita
  • Distruggerà tutte le risorse di Azure

Cominciamo subito!

Panoramica del progetto

Questo progetto sarà suddiviso in sei sezioni principali. Sono:

Preparazione delle risorse di Azure

In questa sezione, imparerai come configurare tutte le risorse preliminari in Azure. Qui imparerai a:

  • Creare un service principal Azure per varie attività nel pipeline
  • Configurare un Azure Key Vault con segreti da utilizzare nel pipeline
  • Impostare le politiche di accesso appropriate per le distribuzioni ARM e l’utilizzo del pipeline

Preparazione di Azure DevOps

Una volta configurate tutte le risorse di Azure, è il momento di preparare Azure DevOps per il tuo pipeline. In questa sezione, farai quanto segue:

Panoramica degli script/modello

Ci sono vari artefatti che vanno con questo progetto, incluso il modello ARM per creare il server e i test Pester. In questa sezione, copriremo brevemente ciò che il modello sta provvedendo e cosa esattamente Pester sta testando nel flusso di lavoro.

Creazione del flusso di lavoro

In questa sezione è dove inizia il vero divertimento. Inizierai a configurare il flusso di lavoro effettivo. Qui imparerai come impostare tutta questa orchestrazione tramite un singolo file YAML.

Creerai il flusso di lavoro utilizzando l’esperienza dell’interfaccia utente del flusso di lavoro a più fasi. Al momento della scrittura, questa funzionalità è in anteprima.

Dimostrazione del flusso di lavoro

Una volta costruito il flusso di lavoro, è necessario vederlo in esecuzione! In questa sezione imparerai come attivare il flusso di lavoro e semplicemente osservare la magia accadere.

Pulizia

E infine, dal momento che si tratta solo di una dimostrazione, avrai accesso a uno script per eliminare tutto ciò che è stato costruito durante il tutorial.

Ti sembra molto? Lo è! Ma non preoccuparti, imparerai passo dopo passo affrontando ogni compito uno alla volta.

Se desideri uno script con tutti i comandi Azure CLI utilizzati per creare questo flusso di lavoro, puoi trovarlo nel repository GitHub di ServerAutomationDemo come demo.ps1.

Prerequisiti

Stai per imparare molto, ma ci si aspetta che tu porti qualcosa al tavolo. Se hai intenzione di seguirmi, assicurati di avere quanto segue:

ARM deployments allowed to access the key vault
  • Cloud Shell o PowerShell 6+ se viene eseguito localmente – Gli esempi potrebbero funzionare in Windows PowerShell, ma non sono stati testati. Tutti gli esempi verranno eseguiti localmente tramite una console PowerShell, ma il Cloud Shell funzionerà altrettanto bene. Automatizzerai la creazione della pipeline.
  • Azure CLI installato (se viene eseguito localmente) – Imparerai come eseguire attività in questo articolo con Azure CLI. Tuttavia, le stesse procedure possono essere eseguite anche tramite il portale di Azure, PowerShell o l’Azure SDK.

Avviso: Le azioni che stai per eseguire costano denaro reale, a meno che tu non abbia qualche credito Azure. Le risorse che comportano costi maggiori che creerai in Azure sono una macchina virtuale, ma solo temporaneamente.

Prima di iniziare

In questo tutorial, effettuerai molte configurazioni. Prima di iniziare, assicurati di avere a portata di mano quanto segue.

  • Il nome dell’abbonamento Azure su cui verranno distribuite le risorse: negli esempi verrà utilizzato Adam the Automator.
  • L’ID dell’abbonamento
  • L’ID del tenant di Azure AD
  • Il nome dell’organizzazione DevOps – negli esempi useremo adbertram.
  • La regione in cui si stanno posizionando le risorse – negli esempi useremo eastus.
  • Il nome del gruppo di risorse di Azure in cui inserire il vault delle chiavi temporanee – negli esempi useremo ServerAutomationDemo.
  • A password to assign to the local administrator account on a deployed VM – the examples will use “I like azure.”.
  • L’URL del repository GitHub – negli esempi useremo https://github.com/adbertram/ServerAutomationDemo.

Accesso con Azure CLI

Sii pronto a lavorare molto con Azure CLI nell’articolo. Amo i cmdlet di Azure PowerShell, ma Azure CLI è attualmente in grado di eseguire più attività di DevOps.

Il tuo primo compito è accedere a una console di PowerShell 6+. Una volta nella console, autenticati su Azure usando il comando az login. Questo comando aprirà una finestra del browser e ti chiederà le credenziali del tuo account.

Una volta autenticato, assicurati di impostare il tuo abbonamento come predefinito. Impostarlo come predefinito eviterà di doverlo specificare costantemente.

az login
az account set --subscription 'Adam the Automator'

Preparazione delle risorse di Azure

Una volta effettuato l’accesso con Azure CLI, è tempo di mettersi al lavoro. Una pipeline di Azure ha molte dipendenze diverse e vari parametri da impostare. In questa prima sezione, imparerai come eseguire alcune configurazioni e preparare l’ambiente per la tua pipeline.

Installazione dell’estensione Azure CLI DevOps

Avere un modo per creare i vari componenti di Azure DevOps con Azure CLI è necessario. Per impostazione predefinita, questa funzionalità non è inclusa. Per gestire Azure DevOps da Azure CLI, è necessario installare l’estensione DevOps.

Felizmente, l’installazione dell’estensione è una singola riga, come mostrato di seguito.

az extension add --name azure-devops

Una volta installata l’estensione, imposta l’organizzazione come predefinita per evitare di specificarla ogni volta.

az devops configure --defaults organization=https://dev.azure.com/adbertram

Creazione del gruppo di risorse

Anche se la pipeline creerà un gruppo di risorse temporaneo, è consigliabile creare anche uno per le risorse utilizzate in questa demo. In particolare, in questo gruppo di risorse verrà creato un Azure Key Vault.

az group create --location "eastus" --name "ServerAutomationDemo"

Creazione del Service Principal di Azure

Il compito successivo è creare un Azure service principal. Avrai bisogno di un Azure service principal per autenticarti alla Azure Key Vault. Utilizzerai anche questo service principal per autenticare una connessione di servizio. Crea il service principal sia per la key vault che per la futura distribuzione ARM come mostrato di seguito.

$spIdUri = "http://ServerAutomationDemo"
$sp = az ad sp create-for-rbac --name $spIdUri | ConvertFrom-Json

A questo punto, sarebbe una buona idea salvare il valore di $sp.appId da qualche parte. Quando arrivi a costruire il pipeline in seguito, avrai bisogno di questo valore!

ConvertFrom-Json. Poiché Azure CLI restituisce solo stringhe JSON, è più facile fare riferimento alle proprietà se convertite in un oggetto PowerShell.

Creazione della Key Vault

La pipeline in questo tutorial deve fare riferimento a un paio di password. Invece di memorizzare le password in chiaro, facciamolo nel modo corretto. Tutte le informazioni sensibili saranno memorizzate in un Azure Key Vault.

Per creare la key vault, utilizza il comando az keyvault create come mostrato di seguito. Questo comando crea la key vault nel gruppo di risorse precedentemente creato. Nota anche l’interruttore enabled-for-template-deployment. Questo cambia la policy di accesso alla key vault per consentire alla futura distribuzione ARM di accedere alla key vault.

az keyvault create --location $region --name "ServerAutomationDemo-KV" --resource-group "ServerAutomationDemo" --enabled-for-template-deployment true
Allowing ARM to access the keyvault

Creazione delle chiavi segrete della Key Vault.

Una volta creato il key vault, è il momento di creare le segrete. Per questa demo, crea due segrete chiamate ServerAutomationDemo-AppPw e StandardVmAdminPassword. La password AppPw è la password per il principale di servizio. La password VM sarà assegnata all’account amministratore locale sulla VM distribuita.

az keyvault secret set --name "ServerAutomationDemo-AppPw" --value $sp.password --vault-name "ServerAutomationDemo-KV"
az keyvault secret set --name StandardVmAdminPassword --value "I like azure." --vault-name "ServerAutomationDemo-KV"

Nella nota che segue stai utilizzando le variabili di PowerShell precedentemente definite come esempio. Qui fornisci la password del principale di servizio ($sp.password) ottenuta in precedenza.

Consentire al Pipeline di accedere al Key Vault

Successivamente, la pipeline ha bisogno dell’autorizzazione per accedere al key vault. Rilassa un po’ la policy di accesso al key vault. Fornisci al principale di servizio creato le autorizzazioni get e list per gestire le segrete del key vault.

az keyvault set-policy --name "ServerAutomationDemo-KV" --spn $spIdUri --secret-permissions get list

Preparare Azure DevOps

Ora hai completato tutti i preparativi delle risorse di Azure. È ora di fare qualche lavoro di preparazione in Azure DevOps.

Installare l’Estensione Pester

Il primo passaggio da eseguire è l’installazione dell’estensione PesterRunner per Azure DevOps. La pipeline eseguirà due set di test Pester per verificare che il deployment ARM della VM sia stato eseguito correttamente. Uno dei modi più semplici per eseguire i test Pester è con l’estensione PesterRunner.

Installa l’estensione utilizzando il comando seguente.

az devops extension install --extension-id PesterRunner --publisher-id Pester

Creazione del Progetto Azure DevOps

È ora il momento di creare il progetto in cui verrà creato il pipeline. Creare un pipeline Azure DevOps è semplice con Azure CLI. Esegui semplicemente i comandi di seguito per creare il progetto e impostarlo come predefinito.

az devops project create --name "ServerAutomationDemo"
az devops configure --defaults project=ServerAutomationDemo

Creazione delle connessioni al servizio

Il tuo pipeline deve autenticarsi a due servizi: ARM e il tuo repository GitHub. Per fare ciò, devono essere create due connessioni al servizio.

Innanzitutto, crea il punto di connessione al servizio ARM. Il comando di seguito richiederà la password del service principal. Assicurati di visualizzarla prima sulla console e copiarla negli appunti.

Assicurati di inserire l’ID della sottoscrizione, l’ID dell’entità tenant e sostituisci il nome della sottoscrizione di seguito.

## Esegui $sp.password e copiala negli appunti
$sp.Password

## crea il punto di connessione al servizio
az devops service-endpoint azurerm create --azure-rm-service-principal-id $sp.appId --azure-rm-subscription-id "YOURSUBSCRIPTIONIDHERE" --azure-rm-subscription-name 'Adam the Automator' --azure-rm-tenant-id $tenantId --name 'ARM'

Successivamente, crea una connessione al servizio per GitHub. Poiché il pipeline verrà attivato tramite un commit Git, sarà in grado di leggere il repo.

A questo punto, il token di accesso personale di GitHub sarà molto utile. Di seguito, dovrai incollare nuovamente la password del service principal. Stai usando lo stesso service principal per entrambe le connessioni al servizio.

$gitHubServiceEndpoint = az devops service-endpoint github create --github-url 'https://github.com/adbertram/ServerAutomationDemo' --name 'GitHub' | ConvertFrom-Json

## incolla il token di GitHub quando richiesto

Creazione del gruppo di variabili

Il pipeline farà riferimento alle segrete di Azure Key Vault per due password. Per farlo in modo sicuro, è necessario creare un gruppo di variabili e collegarlo a Key Vault.

Per prima cosa, crea il gruppo di variabili come mostrato di seguito.

az pipelines variable-group create --name "ServerAutomationDemo" --authorize true --variables foo=bar

Si noti la variabile foo=bar? Non viene utilizzata, ma è necessaria una singola variabile per creare il gruppo di variabili.

Collegamento del gruppo di variabili a un Key Vault

A questo punto, purtroppo, dovrai accedere al portale di Azure DevOps. Al momento della stesura di questo documento, Azure CLI non offre un modo per collegare un Key Vault a un gruppo di variabili.

Accedi al progetto di Azure DevOps e fai clic su Libreria. Dovresti vedere il gruppo di variabili ServerAutomationDemo come mostrato di seguito. Fai clic sul gruppo di variabili ServerAutomationDemo.

Available variable group

Una volta nel gruppo di variabili, fai clic su Collega segreti da un Key Vault di Azure come variabili. Verrai avvertito che verranno cancellate tutte le variabili e fai clic su Conferma. Di seguito, ti verrà mostrato come fare. Questa azione è accettabile poiché la variabile foo era temporanea fin dall’inizio.

Linking variable group to pipeline

Dopo aver confermato, seleziona la connessione al servizio ARM e il Key Vault ServerAutomationDemo-KV creato in precedenza, come mostrato di seguito. Fai clic su Aggiungi.

Setting the service connection

Ora verifica entrambe le segrete create in precedenza, come mostrato di seguito, e fai clic su OK e Salva per salvare le modifiche.

Selecting keyvault secrets for the pipeline to use

Panoramica dei file di progetto

Se sei arrivato fin qui, congratulazioni! Sei ora pronto per iniziare a costruire il pipeline. Ma aspetta…c’è di più!

Per rendere reale la creazione di un Azure Pipeline, questo tutorial costruisce un pipeline completo con test “unit” e “acceptance”. Questo rende il tutorial più interessante, ma richiede anche alcune spiegazioni aggiuntive su ciò che sta accadendo.

Nel repository di GitHub di questo tutorial, troverai alcuni file come mostrato di seguito. Ora potrebbe essere un buon momento per clonare questo repository o costruirne uno tuo a partire dai file.

GitHub files list
  • azure-pipelines.yml – Il file YAML finale del pipeline
  • connect-azure.ps1 – Script PowerShell per l’autenticazione a un abbonamento Azure
  • server.infrastructure.tests.ps1 – Un semplice test Pester per confermare che la configurazione della VM sia corretta
  • server.json – Un modello Azure ARM per la creazione di una VM
  • server.parameters.json – Un modello di parametri Azure ARM che fornisce i valori dei parametri al modello ARM.

Assicurati di sostituire il tuo ID di abbonamento e il nome di Key Vault per il Key Vault IT nel file server.parameters.json.

  • server.templates.tests.ps1 – Test Pester “unit” per confermare la validità del modello ARM

Vedrai come questi file si integrano nel pipeline tra poco.

Creazione del pipeline

Assumendo che tu abbia clonato il mio repository GitHub o che ne abbia creato uno tuo, è ora di creare il pipeline! Per farlo, esegui il comando az pipelines create. Il comando qui sotto crea un pipeline chiamato ServerAutomationDemo utilizzando il repository GitHub fornito come trigger. Esaminerà il branch master e utilizzerà la connessione al servizio creata in precedenza.

az pipelines create --name "ServerAutomationDemo" --repository "https://github.com/adbertram/ServerAutomationDemo" --branch master --service-connection $gitHubServiceEndpoint.id --skip-run

A seconda che tu abbia o meno il file azure-pipelines.yml nel tuo repository GitHub, potresti ricevere o meno un feedback come quello riportato di seguito. In ogni caso, la tua console avrà un aspetto simile. Assicurati di avere pronto il tuo token di accesso personale di GitHub!

Creating the Azure DevOps pipeline with the Azure CLI

Recensione del pipeline YAML

A questo punto, il tuo pipeline è pronto per essere eseguito, ma è importante capire prima il pipeline YAML. Dai un’occhiata al file azure-pipelines.yml. Questo file rappresenta il pipeline quando si utilizza la funzionalità di pipeline YAML multi-stage.

Analizziamo le varie componenti che compongono questo pipeline YAML.

Il Trigger

Dato che stai creando un pipeline CI che viene eseguito automaticamente, hai bisogno di un trigger. Il trigger qui sotto istruisce il pipeline di eseguirsi quando viene rilevato un commit nel branch master di Git.

Fai attenzione anche alla sezione paths. Per impostazione predefinita, se non includi o escludi specificamente file o directory in una build CI, il pipeline verrà eseguita quando viene effettuato un commit su qualsiasi file. Poiché questo progetto si basa interamente su un modello ARM, non desideri eseguire la pipeline se, ad esempio, apporti una modifica a un test Pester.

trigger:
  branches:
    include:
      - master
  paths:
    include:
      - server.json
      - server.parameters.json

Il Pool

Ogni build ha bisogno di un agente. Ogni agente build deve essere eseguito su una VM. In questo caso, la VM sta utilizzando l’immagine VM ubuntu-latest. Questa immagine è l’immagine predefinita definita quando la build è stata creata originariamente. Non è stata modificata a causa della “semplicità” di questa pipeline.

pool:
  vmImage: "ubuntu-latest"

Variabili

Successivamente, abbiamo tutte le variabili e il gruppo di variabili. Le varie attività in questa pipeline richiedono la lettura di valori come l’ID sottoscrizione Azure, l’ID tenant e l’ID applicazione per il service principal e così via. Invece di replicare valori statici in ogni attività, vengono definiti come variabili.

Fai anche attenzione all’elemento group. Questo elemento fa riferimento al gruppo di variabili creato in precedenza. Assicurati di sostituire subscription_id e tenant_id in questo momento.

Ricordi nella sezione Creazione del service principal di Azure di aver salvato il valore di $sp.appId da qualche parte? È qui che ti servirà. Assegna il valore di quell’ID applicazione del service principal a application_id come mostrato di seguito.

variables:
    - group: ServerAutomationDemo
    - name: azure_resource_group_name
      value: "ServerProvisionTesting-$(Build.BuildId)"
    - name: subscription_id
      value: "XXXXXXXXXXXXX"
    - name: application_id
      value: "XXXXXXXXXXXXX"
    - name: tenant_id
      value: "XXXXXXXXXXXX"

Nota il valore della variabile azure_resource_group_name. All’interno di quel valore vedrai $(Build.BuildId). Questa è una variabile di sistema che rappresenta l’ID della build del job corrente. In questo contesto, viene utilizzata per garantire che il gruppo di risorse temporaneo creato sia unico.

Attività di preparazione di PowerShell

Il prossimo set di attività invoca codice PowerShell. Questo esempio di pipeline utilizza PowerShell per creare e rimuovere un gruppo di risorse temporaneo per scopi di test. In queste attività di distribuzione, vedrai due esempi di invocazione di codice PowerShell.

La prima attività invoca uno script chiamato connect-azure.ps1 che esiste nel repository GitHub. Questa attività autentica l’accesso all’abbonamento di Azure per i successivi comandi di Azure PowerShell.

Questa attività di connessione Azure PowerShell chiama lo script e passa un valore di segreto di key vault (ServerAutomationDemo-AppPw) e le variabili di pipeline subscription_id, application_id e tenant_id.

La seconda attività sta eseguendo codice PowerShell inline, il che significa che non esiste già uno script. Invece, il codice PowerShell viene definito nella stessa pipeline YAML utilizzando il valore della variabile di pipeline azure_resource_group_name.

- task: PowerShell@2
  inputs:
    filePath: "connect-azure.ps1"
    arguments: '-ServicePrincipalPassword "$(ServerAutomationDemo-AppPw)" -SubscriptionId $(subscription_id) -ApplicationId $(application_id) -TenantId $(tenant_id)'
- task: PowerShell@2
  inputs:
    targetType: "inline"
    script: New-AzResourceGroup -Name $(azure_resource_group_name) -Location eastus -Force

Test del modello Pester

Ecco il primo test Pester. In una pipeline di CI/CD come questa, è importante avere diversi livelli di test. Se stessi creando una pipeline per un progetto software, potresti creare vari test unitari.

Dal momento che questo esempio di pipeline è costruito attorno a una singola distribuzione di una VM ARM, i primi test “unitari” saranno per verificare la validità del modello JSON. All’interno del file server.templates.tests.ps1 è possibile aggiungere quanti test diversi si desidera sul file del modello ARM stesso.

Notare di seguito che la pipeline sta utilizzando vari variabili di sistema. Queste variabili fanno riferimento alla posizione dei file una volta che sono presenti sull’agente di compilazione.

Il task PesterRunner invia i risultati dei test a un file XML che verrà poi letto successivamente nella pipeline.

- task: Pester@0
  inputs:
    scriptFolder: "@{Path='$(System.DefaultWorkingDirectory)/server.template.tests.ps1'; Parameters=@{ResourceGroupName='$(azure_resource_group_name)'}}"
    resultsFile: "$(System.DefaultWorkingDirectory)/server.template.tests.XML"
    usePSCore: true
    run32Bit: False

La distribuzione della VM ARM

Siamo ora giunti alla distribuzione ARM. Dal momento che l’intera pipeline è costruita attorno alla capacità di distribuire una VM, questa è importante! Questo task distribuisce il modello ARM fornendo tutti gli attributi richiesti per realizzarlo.

Si noti l’attributo deploymentOutputs: arm_output. Nel passaggio successivo, un task deve connettersi alla VM che è stata distribuita. Un ottimo modo per ottenere il nome DNS o l’indirizzo IP di questa VM è restituirlo tramite la distribuzione ARM. L’opzione deploymentOutputs crea una variabile di pipeline che può essere referenziata in altri task.

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    deploymentScope: "Resource Group"
    azureResourceManagerConnection: "ARM"
    subscriptionId: "1427e7fb-a488-4ec5-be44-30ac10ca2e95"
    action: "Create Or Update Resource Group"
    resourceGroupName: $(azure_resource_group_name)
    location: "East US"
    templateLocation: "Linked artifact"
    csmFile: "server.json"
    csmParametersFile: "server.parameters.json"
    deploymentMode: "Incremental"
    deploymentOutputs: "arm_output"

Test “Accettazione” Pester

Una volta che la VM è stata distribuita, è necessario assicurarsi che sia stata distribuita correttamente con un test “integrazione” o “accettazione”. Questo task PesterRunner invoca Pester ed esegue un altro set di test relativi all’infrastruttura per garantire che la VM sia stata distribuita con successo.

Si noti che stiamo passando il valore dell’output dell’implementazione ARM tramite il parametro ArmDeploymentJsonOutput. Il file dello script di test Pester ha un parametro definito che prende il valore e legge il nome host DNS della macchina virtuale.

 - task: Pester@0
    inputs:
      scriptFolder: "@{Path='$(System.DefaultWorkingDirectory)/server.infrastructure.tests.ps1'; Parameters=@{ArmDeploymentJsonOutput='$(arm_output)'}}"
      resultsFile: "$(System.DefaultWorkingDirectory)/server.infrastructure.tests.XML"
      usePSCore: true
      run32Bit: False

Puoi vedere di seguito come appare lo script PowerShell server.infrastructure.tests.ps1. Si noti che sta leggendo il nome host DNS della VM per eseguire quindi un semplice controllo delle porte aperte.

$ArmDeploymentOutput = $ArmDeploymentJsonOutput | convertfrom-json

## Esegui i test
describe 'Network Connnectivity' {
    it 'the VM has RDP/3389 open' {
        Test-Connection -TCPPort 3389 -TargetName $ArmDeploymentOutput.hostname.value -Quiet | should -Be $true
    }
}

Eliminazione del test di pulizia “Acceptance”

L’unico motivo per cui il pipeline ha implementato un’infrastruttura era per testare la validità del modello ARM. Poiché questa infrastruttura è solo temporanea, è necessario pulirla. Nell’ultimo passaggio di PowerShell, il pipeline sta rimuovendo il gruppo di risorse creato in precedenza e tutto ciò che contiene.

- task: PowerShell@2
  inputs:
    targetType: "inline"
    script: Get-AzResourceGroup -Name $(azure_resource_group_name) | Remove-AzResourceGroup -Force

Pubblicazione dei risultati del test Pester

E infine, siamo arrivati all’ultimo set di attività. Azure Pipelines ha un’attività chiamata Publish Test Results. Questa attività legge un file XML sull’agente di compilazione e visualizza i risultati dei test in Azure DevOps. Questo è un modo comodo per vedere facilmente i risultati di tutti i test eseguiti.

- task: PublishTestResults@2
  inputs:
    testResultsFormat: "NUnit"
    testResultsFiles: "$(System.DefaultWorkingDirectory)/server.infrastructure.tests.XML"
    failTaskOnFailedTests: true

- task: PublishTestResults@2
  inputs:
    testResultsFormat: "NUnit"
    testResultsFiles: "$(System.DefaultWorkingDirectory)/server.template.tests.XML"
    failTaskOnFailedTests: true
The Tests section of a pipeline run

Utilizzo del Azure DevOps Pipeline

Infine, siamo pronti per eseguire il pipeline e vedere come funziona. Nell’interfaccia utente web di Azure DevOps, assicurati di essere nel progetto ServerAutomationDemo. Una volta qui, fai clic su Pipelines e quindi dovresti vedere il pipeline ServerAutomationDemo.

Un modo per eseguire il pipeline è fare clic sui tre puntini sulla destra come mostrato di seguito. Quindi, fai clic su Esegui pipeline. Questo avvierà l’automazione.

Running a pipeline

Il pipeline continuerà a procedere e eseguirà ogni attività come indicato. Alla fine, dovresti vedere tutti i segni di spunta verdi per ogni attività eseguita dal lavoro, come mostrato di seguito.

Successful job task execution

Pulizia

Dopo aver sperimentato il pipeline e tutto ciò che hai realizzato qui, dovresti pulire le cose. Dopotutto, questo era solo un tutorial e non un compito di produzione!

Di seguito troverai alcuni comandi per pulire tutto ciò che è stato creato in questo articolo. Questo codice rimuove il principale di servizio, l’applicazione Azure AD, il gruppo di risorse e tutto al suo interno e il progetto Azure DevOps.

$spId = ((az ad sp list --all | ConvertFrom-Json) | ? { '<https://ServerAutomationDemo>' -in $_.serviceprincipalnames }).objectId
az ad sp delete --id $spId

## Rimuovi il gruppo di risorse
az group delete --name "ServerAutomationDemo" --yes --no-wait

## rimuovi il progetto
$projectId = ((az devops project list | convertfrom-json).value | where { $_.name -eq 'ServerAutomationDemo' }).id
az devops project delete --id $projectId --yes

Riepilogo

Questo tutorial era pensato per darti un’idea di come costruire un vero pipeline di automazione dell’infrastruttura di Azure DevOps. Anche se ci sono innumerevoli altri modi per costruire pipeline come questa, le competenze che hai appreso in questo tutorial dovrebbero aiutarti in molte configurazioni diverse.

Ora esci e inizia a automatizzare di più!

Source:
https://adamtheautomator.com/azure-devops/