Construir canalizaciones de Azure DevOps del mundo real para plantillas de ARM

Tutoriales
DevOps

Cuando buscas en línea, encontrarás varias publicaciones de blogs, documentación y tutoriales sobre Azure DevOps. Todos estos recursos son valiosos, pero rara vez te guían a través de un escenario del mundo real. Muchos pasan por alto el aspecto de la seguridad, dejando contraseñas en texto claro por simplicidad o un producto final que básicamente no hace nada. Vamos a cambiar eso.

En este artículo/tutorial, aprenderás de principio a fin cómo construir un pipeline de lanzamiento de Azure DevOps que automatiza la infraestructura. Más específicamente, aprenderás cómo usar Azure DevOps para construir un pipeline de implementación continua que provisiona máquinas virtuales de Azure.

Al final de este proyecto, tendrás un pipeline de Azure completamente funcional. A partir de una sola confirmación en un repositorio de GitHub, hará lo siguiente:

  • Construirá un grupo de recursos temporal de Azure
  • Provisionará una VM de Azure mediante una plantilla de ARM
  • Configurará dicha plantilla de ARM en un pipeline de CI/CD
  • Al realizar cualquier cambio en la plantilla, iniciará una prueba de validación de la plantilla
  • Implementará la plantilla de ARM en Azure
  • Probará la infraestructura implementada
  • Eliminará todos los recursos de Azure

¡Vamos a sumergirnos de lleno!

Descripción general del proyecto

Este proyecto se dividirá en seis secciones principales. Son las siguientes:

Preparación de recursos de Azure

En esta sección, aprenderás cómo configurar todos los recursos prerrequisitos en Azure. Aquí harás lo siguiente:

  • Crear un principal de servicio de Azure para diversas tareas en el pipeline
  • Configurar un Almacén de claves de Azure con secretos para que use el pipeline
  • Establecer políticas de acceso apropiadas para despliegues de ARM y uso del pipeline

Preparación de Azure DevOps

Una vez que tenga todos los recursos de Azure configurados, es hora de preparar Azure DevOps para su pipeline. En esta sección, usted:

Vista general del script/plantilla

Hay varios artefactos que acompañan a este proyecto, incluyendo la plantilla ARM para construir el servidor y las pruebas Pester. En esta sección, cubriremos brevemente qué está provisionando la plantilla y qué exactamente está probando Pester en el pipeline.

Creación del pipeline

En esta sección es donde la diversión real comienza. Comenzarás a configurar el pipeline real. Aquí aprenderás cómo configurar toda esta orquestación mediante un único archivo YAML.

Construirás el pipeline utilizando la experiencia de interfaz de usuario del Pipeline de múltiples etapas. En el momento de escribir esto, esta característica está en vista previa.

Demostración del pipeline

Una vez que el pipeline esté construido, ¡necesitas verlo en acción! En esta sección aprenderás cómo activar el pipeline y simplemente observar cómo sucede la magia.

Limpieza

Y finalmente, dado que esto es solo una demostración, tendrás acceso a un script para desmontar todo lo construido durante el tutorial.

¿Suena como mucho? ¡Lo es! Pero no te preocupes, aprenderás paso a paso mientras atacas cada tarea una por una.

Si deseas un script con todos los comandos de Azure CLI utilizados para construir este pipeline, puedes encontrarlo en el repositorio GitHub de ServerAutomationDemo como demo.ps1.

Prerrequisitos

Vas a aprender mucho, pero también se espera que aportes algunas cosas. Si planeas seguir, asegúrate de tener lo siguiente:

ARM deployments allowed to access the key vault
  • Cloud Shell o PowerShell 6+ si se ejecuta de forma local: Los ejemplos pueden funcionar en Windows PowerShell, pero no se han probado. Todos los ejemplos se realizarán de forma local mediante una consola de PowerShell, pero Cloud Shell también funcionará igual de bien. Automatizarás la construcción del canalización.
  • Azure CLI instalado (si se ejecuta de forma local): Aprenderás cómo realizar tareas en este artículo con Azure CLI. Sin embargo, los mismos procedimientos también se pueden realizar a través del Portal de Azure, PowerShell o el SDK de Azure.

Advertencia: Las acciones que estás a punto de realizar tienen un costo real a menos que tengas algún crédito de Azure. Los recursos que más costarán en Azure serán una VM, pero solo temporalmente.

Antes de empezar

Vas a hacer mucha configuración en este tutorial. Antes de comenzar, asegúrate de tener a mano los siguientes elementos.

  • El nombre de la suscripción de Azure a la cual se desplegarán los recursos: los ejemplos utilizarán Adam the Automator.
  • El ID de la suscripción
  • El ID del inquilino de Azure AD
  • El nombre de la organización de DevOps, los ejemplos utilizarán adbertram.
  • La región donde se colocarán los recursos, los ejemplos utilizarán eastus.
  • El nombre del grupo de recursos de Azure para colocar el almacén de claves temporal, los ejemplos utilizarán ServerAutomationDemo.
  • A password to assign to the local administrator account on a deployed VM – the examples will use “I like azure.”.
  • La URL del repositorio de GitHub, los ejemplos utilizarán https://github.com/adbertram/ServerAutomationDemo.

Inicio de sesión con Azure CLI

Prepárese para realizar mucho trabajo con Azure CLI en el artículo. Me encantan los cmdlets de Azure PowerShell, pero actualmente, Azure CLI es capaz de realizar más tareas de DevOps.

Su primera tarea es llegar a una consola de PowerShell 6 o superior. Una vez en la consola, autentíquese en Azure usando el comando az login. Este comando abrirá una ventana del navegador y le pedirá sus credenciales.

Una vez autenticado, asegúrese de establecer su suscripción como la predeterminada. Establecerla como predeterminada evitará que tenga que especificarla constantemente.

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

Preparación de Recursos de Azure

Una vez que hayas iniciado sesión con Azure CLI, es hora de ponerse manos a la obra. Un Azure Pipeline tiene muchas dependencias diferentes y varios controles para ajustar. En esta primera sección, aprenderás a realizar algunas configuraciones y preparar tu entorno para tu pipeline.

Instalación de la Extensión de Azure CLI para DevOps

Necesitarás una manera de construir los diversos componentes de Azure DevOps con Azure CLI. Por defecto, no incluye esa funcionalidad. Para administrar Azure DevOps desde Azure CLI, deberás instalar la extensión de DevOps.

Afortunadamente, la instalación de la extensión es una sola línea, como se muestra a continuación.

az extension add --name azure-devops

Una vez que la extensión haya sido instalada, configura tu organización como la predeterminada para evitar especificarla una y otra vez.

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

Creación del Grupo de Recursos

Aunque el pipeline creará un grupo de recursos temporal, también deberías crear uno para cualquier recurso que se levante en esta demostración. Más específicamente, este grupo de recursos es donde crearás un Azure Key Vault.

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

Creación del Azure Service Principal

La siguiente tarea es crear un principal de servicio de Azure. Vas a necesitar un principal de servicio de Azure para autenticarte en Azure Key Vault. También utilizarás este principal de servicio para autenticar una conexión de servicio. Crea el principal de servicio tanto para el almacén de claves como para la implementación de ARM eventual, como se muestra a continuación.

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

En este momento, sería una buena idea guardar el valor de $sp.appId en algún lugar. ¡Cuando llegues a construir la canalización más adelante, lo necesitarás!

Notarás algunos comandos de PowerShell en los ejemplos, por ejemplo, ConvertFrom-Json. Dado que la CLI de Azure solo devuelve cadenas JSON, es más fácil hacer referencia a las propiedades si se convierten en un objeto de PowerShell.

Creando el almacén de claves

La canalización en este tutorial necesita hacer referencia a un par de contraseñas. En lugar de almacenar las contraseñas en texto claro, hagámoslo de la manera correcta. Toda la información sensible se almacenará en un almacén de claves de Azure.

Para crear el almacén de claves, utiliza el comando az keyvault create como se muestra a continuación. Este comando crea el almacén de claves en el grupo de recursos creado anteriormente. También observa el interruptor enabled-for-template-deployment. Esto cambia la política de acceso del almacén de claves para permitir que la implementación de ARM futura acceda al almacén de claves.

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

Creando secretos del almacén de claves.

Una vez creada la bóveda de claves, es hora de crear los secretos. Para esta demostración, crea dos secretos llamados ServerAutomationDemo-AppPw y StandardVmAdminPassword. La contraseña AppPw es la contraseña para el principal de servicio. La contraseña de la VM se asignará a la cuenta de administrador local en la VM desplegada.

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"

Ten en cuenta que estás usando variables de PowerShell definidas previamente en este ejemplo. Aquí estás proporcionando la contraseña del principal de servicio ($sp.password) obtenida anteriormente.

Permitiendo que el Pipeline Acceda a la Bóveda de Claves

A continuación, el pipeline necesita permiso para acceder a la bóveda de claves. Relaja un poco la política de acceso a la bóveda de claves. Proporciona al principal de servicio creado con get y list permisos para gestionar secretos de la bóveda de claves.

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

Preparando Azure DevOps

Ahora tienes toda la preparación de recursos de Azure lista. Es hora de hacer algunos trabajos de preparación en Azure DevOps.

Instalando la Extensión Pester

La primera tarea a realizar es instalar la extensión PesterRunner de Azure DevOps. El pipeline va a ejecutar dos conjuntos de pruebas Pester para asegurarse de que el despliegue de ARM de la VM fue exitoso. Una de las formas más sencillas de ejecutar pruebas Pester es con la extensión PesterRunner.

Instala la extensión usando el comando a continuación.

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

Creando el Proyecto de Azure DevOps

Ahora es el momento de crear el proyecto en el que se creará el pipeline. Crear un pipeline de Azure DevOps es muy sencillo con Azure CLI. Simplemente ejecuta los comandos a continuación para crear el proyecto y establecerlo como tu predeterminado.

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

Creando las conexiones de servicio

Tu pipeline necesita autenticarse en dos servicios: ARM y tu repositorio de GitHub. Para hacer esto, se deben crear dos conexiones de servicio.

Primero, crea el punto de conexión del servicio ARM. El comando a continuación solicitará la contraseña del principal del servicio. Asegúrate de mostrarla primero en la consola y copiarla en tu portapapeles.

Asegúrate de completar tu ID de suscripción, ID de inquilino y reemplazar el nombre de la suscripción a continuación.

## Ejecuta $sp.password y cópialo al portapapeles
$sp.Password

## crea el punto de conexión del servicio
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'

A continuación, crea una conexión de servicio para GitHub. Dado que el pipeline se activará mediante un commit de Git, necesitará poder leer el repositorio.

En este punto es donde ese token de acceso personal de GitHub resulta útil. A continuación, también deberás pegar nuevamente la contraseña del principal del servicio. Estás utilizando el mismo principal del servicio para ambas conexiones de servicio.

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

## pega el token de GitHub cuando se te solicite

Creando el grupo de variables

El pipeline hará referencia a secretos del almacén de claves para dos contraseñas. Para hacerlo de manera segura, debes crear un grupo de variables y vincularlo al almacén de claves.

Primero, crea el grupo de variables como se muestra a continuación.

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

¿Notas la variable foo=bar? No se utiliza, pero se requiere una sola variable para crear el grupo de variables.

Vincular el Grupo de Variables a un Almacén de Claves

En este punto, lamentablemente, tendrás que ir al portal de Azure DevOps. Hasta la fecha de esta escritura, la CLI de Azure no tiene forma de vincular un almacén de claves a un grupo de variables.

Navega al proyecto de Azure DevOps y haz clic en Library. Deberías ver el grupo de variables ServerAutomationDemo como se muestra a continuación. Haz clic en el grupo de variables ServerAutomationDemo.

Available variable group

Una vez en el grupo de variables, haz clic en Vincular secretos desde un almacén de claves de Azure como variables. Al hacerlo, se te advertirá que borrarás todas las variables y haz clic en Confirmar. Verás cómo hacer esto a continuación. Esta acción está bien ya que la variable foo era temporal desde el principio.

Linking variable group to pipeline

Una vez confirmado, selecciona la conexión de servicio ARM y el almacén de claves ServerAutomationDemo-KV creado anteriormente como se muestra a continuación. Haz clic en Agregar.

Setting the service connection

Ahora verifica ambos secretos creados anteriormente como se muestra a continuación y haz clic en OK y Guardar para guardar los cambios.

Selecting keyvault secrets for the pipeline to use

Descripción general de los archivos del proyecto

Si has llegado hasta aquí, ¡felicidades! Ahora estás listo para empezar a construir el pipeline. Pero espera… ¡hay más!

Para hacer que la construcción de un Azure Pipeline sea más realista, este tutorial construye un pipeline completo con pruebas “unitarias” y “de aceptación”. Esto hace que el tutorial sea más interesante, pero también requiere una explicación adicional sobre lo que está sucediendo.

En el repositorio de GitHub de este tutorial, encontrarás algunos archivos como se muestra a continuación. Ahora sería un buen momento para clonar este repositorio o construir el tuyo propio a partir de los archivos.

GitHub files list
  • azure-pipelines.yml – El YAML final del pipeline
  • connect-azure.ps1 – Script de PowerShell para autenticarse en una suscripción de Azure
  • server.infrastructure.tests.ps1 – Una prueba simple de Pester para confirmar que la configuración de la máquina virtual es correcta
  • server.json – Una plantilla de ARM de Azure para aprovisionar una máquina virtual
  • server.parameters.json – Una plantilla de parámetros de ARM de Azure que proporciona valores de parámetros a la plantilla de ARM.

Asegúrate de reemplazar tu ID de suscripción y el nombre del almacén de claves para el almacén de claves IT en el archivo server.parameters.json.

  • server.templates.tests.ps1 – Pruebas “unitarias” de Pester para confirmar que la plantilla de ARM es válida

Verás cómo se combinan estos archivos en el pipeline en un momento.

Creando el Pipeline

Suponiendo que has clonado mi repositorio de GitHub o has configurado uno propio, ¡es hora de crear el pipeline! Para hacerlo, ejecuta el comando az pipelines create. El siguiente comando crea un pipeline llamado ServerAutomationDemo utilizando el repositorio de GitHub proporcionado como desencadenador. Se examinará la rama master y se utilizará la conexión de servicio creada anteriormente.

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

Dependiendo de si tienes el archivo azure-pipelines.yml en tu repositorio de GitHub, es posible que recibas o no comentarios como los siguientes. De cualquier manera, tu consola se verá similar. ¡Asegúrate de tener listo tu token de acceso personal de GitHub!

Creating the Azure DevOps pipeline with the Azure CLI

Revisión del Pipeline YAML

En este punto, tu pipeline está listo para ejecutarse, pero es importante entender primero el pipeline YAML. Echa un vistazo al archivo azure-pipelines.yml file. Este archivo es el pipeline cuando se utiliza la función de pipeline YAML de múltiples etapas.

Veamos los diversos componentes que componen este pipeline YAML.

El Desencadenador

Dado que estás construyendo un pipeline CI que se ejecuta automáticamente, necesitas un desencadenador. El desencadenador a continuación instruye al pipeline a ejecutarse cuando se detecta un commit en la rama maestra de Git.

También ten en cuenta la sección paths. De forma predeterminada, si no incluyes específicamente archivos o directorios en una compilación de CI, el flujo de trabajo se ejecutará cuando se haga un commit en cualquier archivo. Debido a que este proyecto gira en torno a una plantilla ARM, no quieres ejecutar el flujo de trabajo si, por ejemplo, hiciste un ajuste a una prueba de Pester.

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

El Grupo

Cada compilación necesita un agente. Cada agente de compilación necesita ejecutarse en una máquina virtual. En este caso, la máquina virtual está utilizando la imagen de VM ubuntu-latest. Esta imagen es la imagen predeterminada que se definió cuando se creó originalmente la compilación. No se ha cambiado debido a la “simplicidad” de este flujo de trabajo.

pool:
  vmImage: "ubuntu-latest"

Variables

A continuación, tenemos todas las variables y el grupo de variables. Las distintas tareas en este flujo de trabajo requieren leer valores como el ID de suscripción de Azure, el ID de inquilino y el ID de aplicación para el principal de servicio, entre otros. En lugar de replicar valores estáticos en cada tarea, se definen como variables.

También ten en cuenta el elemento group. Este elemento hace referencia al grupo de variables que creaste anteriormente. Asegúrate de reemplazar el subscription_id y el tenant_id en este momento.

Recuerda en la sección Creación del principal de servicio de Azure se te recordó guardar el valor de $sp.appId en algún lugar. Aquí es donde lo necesitarás. Asigna el valor de ese ID de aplicación del principal de servicio a application_id como se muestra a continuación.

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"

Toma nota del valor de la variable azure_resource_group_name. Dentro de ese valor verás $(Build.BuildId). Esta es una variable del sistema que representa el ID de compilación del trabajo actual. En este contexto, se utiliza para asegurar que el grupo de recursos temporal creado sea único.

Tareas de Preparación de PowerShell

El siguiente conjunto de tareas invoca código PowerShell. Este ejemplo de canalización utiliza PowerShell para crear y eliminar un grupo de recursos temporal con fines de prueba. En estas tareas de implementación, verás dos ejemplos de invocación de código PowerShell.

La primera tarea invoca un script llamado connect-azure.ps1 que existe en el repositorio de GitHub. Esta tarea autentica la suscripción de Azure para que se ejecuten los comandos de Azure PowerShell posteriores.

Esta tarea de conexión de PowerShell de Azure está llamando al script y pasando un valor de secreto de bóveda de claves (ServerAutomationDemo-AppPw) y las variables de canalización subscription_id, application_id y tenant_id.

La segunda tarea está ejecutando código PowerShell en línea, lo que significa que no existe un script previamente. En cambio, el código PowerShell está definido en el propio YAML de la canalización utilizando el valor de la variable de canalización 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

Prueba de Plantilla de Pester

A continuación, tenemos la primera prueba de Pester. En una canalización de CI/CD como esta, es importante tener diferentes capas de pruebas. Si estuvieras creando una canalización para un proyecto de software, podrías crear varias pruebas unitarias.

Dado que este ejemplo de canalización está construido en torno a la implementación de una sola VM ARM, las primeras pruebas “unitarias” serán para probar la validez del modelo JSON. Dentro del archivo server.templates.tests.ps1 es donde puedes agregar tantas pruebas diferentes en el archivo de plantilla ARM como desees.

Observa a continuación que la canalización está utilizando varias variables del sistema. Estas variables hacen referencia a la ubicación del archivo una vez que llegan al agente de compilación.

La tarea PesterRunner envía los resultados de las pruebas a un archivo XML que luego se leerá más adelante en la canalización.

- 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

Implementación de VM ARM

Ahora hemos llegado a la implementación de ARM. ¡Dado que toda la canalización se construye en torno a la capacidad de implementar una VM, esta es importante! Esta tarea implementa la plantilla ARM proporcionando todos los atributos necesarios para que suceda.

Observa el atributo deploymentOutputs: arm_output. En el siguiente paso, una tarea necesita conectarse a la VM que se implementó. Una excelente manera de obtener el nombre DNS o la dirección IP de esta VM es devolviéndola a través de la implementación de ARM. La opción deploymentOutputs crea una variable de canalización que se puede referenciar en otras tareas.

- 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"

Prueba de “Aceptación” de Pester

Una vez que se ha implementado la VM, debes asegurarte de que se haya implementado correctamente con una prueba de “integración” o “aceptación”. Esta tarea de PesterRunner invoca a Pester y ejecuta otro conjunto de pruebas relacionadas con la infraestructura para asegurar que la VM se haya implementado correctamente.

Ten en cuenta que estamos pasando el valor de la salida de implementación de ARM a través del parámetro ArmDeploymentJsonOutput. El archivo de script de prueba Pester tiene un parámetro definido que toma el valor y lee el nombre de host DNS de la VM.

 - 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

A continuación puedes ver cómo se ve el script de PowerShell server.infrastructure.tests.ps1. Observa que está leyendo el nombre de host DNS de la VM para luego ejecutar una simple comprobación de puerto abierto.

$ArmDeploymentOutput = $ArmDeploymentJsonOutput | convertfrom-json

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

Limpieza de Pruebas “Acceptance”

La única razón por la que se implementó cualquier infraestructura en el pipeline fue para probar la validez de la plantilla de ARM. Dado que esta infraestructura es temporal, necesita ser limpiada. En la última tarea de PowerShell, el pipeline está eliminando el grupo de recursos creado anteriormente y todo lo que contiene.

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

Publicación de Pruebas Pester

Y finalmente, hemos llegado al último conjunto de tareas. Azure Pipelines tiene una tarea llamada Publicar Resultados de Pruebas. Esta tarea lee un archivo XML en el agente de compilación y muestra los resultados de las pruebas en Azure DevOps. Esta es una forma práctica de ver fácilmente los resultados de todas las pruebas ejecutadas.

- 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

Uso del Pipeline de Azure DevOps

Finalmente, estamos listos para ejecutar el pipeline y ver cómo funciona. En la interfaz web de Azure DevOps, asegúrate de estar en el proyecto ServerAutomationDemo. Una vez aquí, haz clic en Pipelines y luego deberías ver el pipeline ServerAutomationDemo.

Una forma de ejecutar el pipeline es hacer clic en los tres puntos en el extremo derecho como se muestra a continuación. Luego, haz clic en Ejecutar pipeline. Esto iniciará la automatización.

Running a pipeline

El canalización continuará y ejecutará cada tarea según las instrucciones. Al final, deberías ver todas las marcas de verificación verdes para cada tarea realizada por el trabajo, como se muestra a continuación.

Successful job task execution

Limpieza

Una vez que hayas jugueteado con la canalización y todo lo que hayas logrado aquí, deberías limpiar las cosas. Después de todo, esto solo estaba destinado a ser un tutorial y no una tarea de producción!

A continuación, encontrarás algunos comandos para limpiar todo lo construido en este artículo. Este código elimina el principal de servicio, la aplicación de Azure AD, el grupo de recursos y todo lo que contiene y el proyecto de Azure DevOps.

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

## Eliminar el grupo de recursos
az group delete --name "ServerAutomationDemo" --yes --no-wait

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

Resumen

Este tutorial pretendía darte una visión de cómo construir una canalización de automatización de infraestructura de Azure DevOps real. Aunque hay innumerables otras formas de construir canalizaciones como esta, las habilidades que has aprendido en este tutorial deberían ayudarte en muchas configuraciones diferentes.

Ahora sal y comienza a automatizar más cosas!

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