Prueba de los recursos después de la implementación

6 minutos

Al validar y obtener una vista previa de la implementación de Bicep, ha podido generar la confianza de que los archivos de Bicep se implementarán correctamente. Pero la implementación no es la historia completa. Una vez que se completa la implementación, también resulta útil comprobar que ha hecho lo que se esperaba.

En esta unidad, obtendrá información sobre las pruebas que puede ejecutar una vez que se complete la implementación. También aprenderá a revertir la implementación si los resultados no son los esperados.

Ejecución de pruebas de comprobación de la compilación y pruebas negativas

Al definir recursos en un archivo de Bicep, el objetivo no es simplemente crear recursos en Azure. Es ofrecer valor a la organización, a la vez que se cumplen los requisitos de la organización. Al validar los archivos de Bicep y obtener una vista previa de ellos, tendrá la confianza de que las definiciones de recursos son válidas, pero no necesariamente sabrá que los recursos realmente harán lo que quiera.

Por ejemplo, imagine que implementa un nuevo servidor lógico de Azure SQL mediante una canalización de implementación de Bicep. La definición de Bicep para el servidor es válida, por lo que pasa las fases de linter y validación preparatoria. El comando hipotético muestra que se creará un servidor, que es lo que esperaba. La implementación también finaliza correctamente. Pero al final del proceso de implementación, es posible que todavía no tenga un servidor de bases de datos en funcionamiento que esté listo para usarse. Entre las razones se pueden incluir las siguientes:

No ha configurado reglas de firewall para permitir que el tráfico de red llegue al servidor.
Ha habilitado la autenticación de Microsoft Entra en su servidor cuando no debía, o viceversa.

Incluso cuando solo va a implementar archivos de Bicep básicos, merece la pena considerar cómo puede validar que los recursos que implementa realmente funcionan y cumplen los requisitos. Estos son algunos ejemplos de cómo puede aplicar este principio:

Al implementar un sitio web, intente acceder a la aplicación web desde la canalización. Compruebe que la canalización se conecta correctamente al sitio web y recibe un código de respuesta válido.
Al implementar una red de entrega de contenido (CDN), intente conectarse a un recurso mediante la CDN. Compruebe que la canalización se conecta correctamente a la CDN y recibe un código de respuesta válido.

Estas pruebas a veces se denominan pruebas de comprobación de la compilación de la infraestructura. Las pruebas de comprobación de la compilación son una forma sencilla de pruebas diseñadas para descubrir problemas importantes en la implementación.

Nota:

No es fácil acceder a algunos recursos de Azure desde un agente de canalización hospedado por Microsoft. Es posible que tenga que considerar la posibilidad de usar un agente autohospedado para ejecutar fases de prueba de comprobación de la compilación si necesitan acceso a los recursos mediante redes privadas.

También es aconsejable realizar pruebas negativas. Las pruebas negativas ayudan a confirmar que los recursos no tienen un comportamiento no deseado. Por ejemplo, al implementar una máquina virtual, un procedimiento recomendado consiste en usar Azure Bastion para conectarse de forma segura a la máquina virtual. Puede agregar una prueba negativa a la canalización para comprobar que no se puede conectar a una máquina virtual directamente mediante Conexión a Escritorio remoto o SSH.

Importante

El objetivo de estas pruebas no es comprobar que Bicep ha implementado los recursos correctamente. Al usar Bicep, se supone que implementará los recursos que especifique en los archivos de Bicep. En su lugar, el objetivo es comprobar que los recursos que ha definido funcionarán para la situación y cumplirán los requisitos.

Ejecución de pruebas desde Azure Pipelines

Hay muchas maneras de ejecutar pruebas en la canalización. En este módulo, se usará Pester, que es una herramienta de código abierto que ejecuta pruebas escritas mediante PowerShell. Puede optar por usar otro marco de prueba o incluso ejecutar las pruebas sin una herramienta de pruebas. Por ejemplo, otra herramienta de prueba que se debe tener en cuenta es PSRule for Azure, que incluye reglas y pruebas predefinidas para Azure. Puede ejecutar la validación en las plantillas y también ejecutar pruebas en los recursos de Azure implementados. En el resumen, se incluirá un vínculo a PSRule.

Cuando se usa un marco de pruebas compatible, Azure Pipelines comprende los resultados de cada prueba. Muestra los resultados de las pruebas junto con la información de ejecución de canalización y realiza el seguimiento del historial de cada prueba en el tiempo. En el ejercicio siguiente, verá cómo puede usar Azure Pipelines con pruebas de comprobación de la compilación de infraestructura.

Transferencia de datos entre pasos y fases

Al dividir la canalización en varias fases, cada una con su propia responsabilidad, en ocasiones es necesario pasar datos entre estas fases. Por ejemplo, una fase podría crear un recurso de Azure con el que otra fase tenga que trabajar. Para poder pasar datos, la segunda fase debe conocer el nombre del recurso que se ha creado. Por ejemplo, nuestra fase de prueba de comprobación de la compilación necesita acceder a los recursos implementados por la fase de implementación.

El archivo de Bicep implementa los recursos, por lo que puede acceder a sus propiedades y publicarlas como salidas de implementación. Puede acceder a una salida de implementación en la canalización. En Azure Pipelines, hay una sintaxis especial para la publicación de variables a fin de que estén disponibles en todas las fases.

En primer lugar, debe publicar una variable de salida para una fase de canalización. Para generar la variable, escribirá una cadena con formato especial en el registro de canalización, que Azure Pipelines sabrá cómo interpretar. En el ejemplo siguiente, una variable denominada myVariable se establece en el valor myValue:

echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"

Azure Pipelines lee e interpreta la cadena del registro de canalización y hace que el valor de la variable esté disponible como salida. Puede combinar este valor con más scripting para publicar el valor de una salida de implementación de Bicep como una variable de salida para una fase de canalización. Verá cómo hacerlo en el ejercicio siguiente.

En segundo lugar, debe hacer que la variable esté disponible para el trabajo de la fase de prueba de comprobación de la compilación. Definirá una variable para el trabajo y usará otra cadena YAML con formato especial:

- stage: SmokeTest
  jobs:
  - job: SmokeTest
    variables:
      myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]

Ahora, cualquier paso dentro del trabajo de prueba de comprobación de la compilación puede acceder al valor myVariable como cualquier otra variable, mediante la sintaxis $(myVariable). Usará una variable en el siguiente ejercicio.

Otros tipos de prueba

Las pruebas funcionales y las pruebas de integración se usan a menudo para validar que los recursos implementados se comportan según lo previsto. Por ejemplo, una prueba de integración podría conectarse al sitio web y enviar una transacción de prueba y, después, esperar para confirmar que la transacción finaliza correctamente. Mediante las pruebas de integración, puede probar la solución que crea el equipo, junto con la infraestructura en la que se ejecuta. En un módulo posterior, verá cómo se pueden agregar estos tipos de pruebas a la canalización.

También es posible ejecutar otros tipos de pruebas desde una canalización de implementación, incluidas las de rendimiento y las de penetración de seguridad. Estas pruebas están fuera del ámbito de este módulo, pero pueden agregar valor a un proceso de implementación automatizado.

Reversión o puesta al día

Imagine que la canalización implementa los recursos de la forma correcta, pero que las pruebas no se realizan correctamente. ¿Qué debe hacer?

Anteriormente en este módulo, ha visto que Azure Pipelines permite crear fases de reversión que se ejecutan cuando se produce un error en una fase anterior. Puede usar este enfoque para crear una fase de reversión cuando la fase de prueba notifique un resultado inesperado. También puede revertir manualmente los cambios o volver a ejecutar toda la canalización si cree que el error se debe a un problema temporal que se ha resuelto desde entonces.

Nota:

Al enviar una implementación a Azure Resource Manager, puede solicitar que vuelva a ejecutar automáticamente la última implementación correcta si se produce un error. Para ello, debe usar el paso de la CLI de Azure para implementar el archivo y agregar el parámetro --rollback-on-error cuando envía la implementación con el comando az deployment group create.

A menudo resulta difícil determinar los pasos que debe realizar una fase de reversión. Por lo general, las implementaciones de Bicep son complejas y no es fácil revertir los cambios. La reversión es especialmente difícil cuando la implementación incluye otros componentes.

Por ejemplo, imagine que la canalización implementa un archivo de Bicep en el que se define una base de datos de Azure SQL a la que después se agregan algunos datos. Cuando se revierte la implementación, ¿se deben eliminar los datos? ¿También se debe quitar la base de datos? Es difícil predecir cómo podrían afectar cada error y cada reversión al entorno en ejecución.

Por esta razón, muchas organizaciones prefieren la puesta al día, lo que significa que corrigen rápidamente el motivo del error y, después, repiten la implementación. Al crear un proceso de implementación automatizada de alta calidad y seguir todos los procedimientos recomendados que ha descubierto a lo largo de estas rutas de aprendizaje, podrá corregir rápidamente los problemas y volver a implementar los archivos de Bicep al tiempo que mantiene una alta calidad.

Sugerencia