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 y obtener una vista previa de los archivos de Bicep, obtiene confianza de la validez de las definiciones de recursos. Pero no siempre sabrá que los recursos realmente harán lo que quiere.

Por ejemplo, imagine que implementa un servidor lógico nuevo de Azure SQL mediante una canalización de flujo de trabajo de Bicep. La definición de Bicep para el servidor es válida, por lo que pasa los trabajos 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 el flujo de trabajo. Compruebe que el flujo de trabajo 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 el flujo de trabajo 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 ejecutores hospedados en GitHub. Es posible que tenga que considerar la posibilidad de usar un ejecutor autohospedado para ejecutar trabajos 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 al flujo de trabajo 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 flujos de trabajo de GitHub

Hay muchas maneras de ejecutar pruebas en el flujo de trabajo. En este módulo, se usa Pester, que es una herramienta de código abierto que ejecuta pruebas escritas mediante PowerShell. Pester está preinstalado en los ejecutores hospedados en GitHub. No es necesario hacer nada especial para usarlo en un paso de script.

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 incluye un vínculo a PSRule.

Al ejecutar pruebas desde un flujo de trabajo, los errores de prueba deben impedir que el flujo de trabajo continúe. En el ejercicio siguiente, verá cómo puede usar flujos de trabajo con pruebas de comprobación de la compilación de infraestructura.

Los resultados de las pruebas se escriben en el registro del flujo de trabajo. Marketplace de GitHub también incluye acciones que no son de Microsoft que pueden mostrar los resultados de las pruebas a lo largo del tiempo y hacerles un seguimiento.

Paso de datos entre los trabajos

Al dividir el flujo de trabajo en varios flujos de trabajo, cada uno con su propia responsabilidad, en ocasiones es necesario pasar datos entre estos trabajos. Por ejemplo, un trabajo podría crear un recurso de Azure con el que otro trabajo tenga que trabajar. Para poder pasar datos, el segundo trabajo debe conocer el nombre del recurso que se ha creado. Por ejemplo, nuestro trabajo de prueba de humo necesita acceder a los recursos implementados por el trabajo 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. Al ejecutar la implementación de Bicep mediante la acción arm-deploy, esta acción almacenará estas salidas de implementación de Bicep en sus salidas de paso. Después, el trabajo que mantiene la acción arm-deploy ahora puede publicar estas salidas de paso como salidas de trabajo. El trabajo hace referencia a la propiedad id del paso, que establecemos en deploy:

deploy:
  runs-on: ubuntu-latest
  environment: Website
  needs: preview
  outputs:
    appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/arm-deploy@v1
    id: deploy
    name: Deploy website
    with:
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Puede acceder a la salida de un trabajo en cualquier trabajo posterior, siempre que dependa del trabajo que genera la salida:

smoke-test:
  runs-on: ubuntu-latest
  needs: deploy
  steps:
  - uses: actions/checkout@v3
  - run: |
      $container = New-PesterContainer `
        -Path 'deploy/Website.Tests.ps1' `
        -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
      Invoke-Pester `
        -Container $container `
        -CI
    name: Run smoke tests
    shell: pwsh

También puede pasar salidas de un script de flujo de trabajo mediante una sintaxis especial. En el resumen se incluyen vínculos a más información.

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 al flujo de trabajo.

También es posible ejecutar otros tipos de pruebas desde un flujo de trabajo 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 el flujo de trabajo implementa los recursos de forma correcta, pero que en las pruebas se produce un error. ¿Qué debe hacer?

Anteriormente en este módulo, ha visto que Acciones de GitHub permite crear trabajos de reversión que se ejecutan cuando se produce un error en un trabajo anterior. Puede usar este enfoque para crear un trabajo de reversión cuando el trabajo de prueba notifique un resultado inesperado. También puede revertir manualmente los cambios o volver a ejecutar todo el flujo de trabajo si cree que el error se debe a un problema temporal que ya se ha resuelto.

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, use el parámetro --rollback-on-error al enviar la implementación mediante el comando az deployment group create de la CLI de Azure.

Por ejemplo, podría agregar un trabajo de reversión al flujo de trabajo. El trabajo de reversión se ejecuta cuando se produce un error en el trabajo de prueba de comprobación de la compilación:

rollback: 
  runs-on: ubuntu-latest
  needs: smoke-test
  if: ${{ always() && needs.smoke-test.result == 'failure' }}
  steps:
  - run: |
      echo "Performing rollback steps..."

El trabajo depende del trabajo de prueba de comprobación de la compilación. Solo se ejecuta cuando se produce un error en la prueba de comprobación de la compilación. De manera predeterminada, Acciones de GitHub detiene el flujo de trabajo siempre que se produce un error en un trabajo anterior. La condición if incluye una comprobación always() para invalidar este comportamiento. Sin always() en la expresión, el trabajo de reversión se omitirá siempre que se produzca un error en un trabajo anterior.

A menudo resulta difícil determinar los pasos que debe realizar un trabajo 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 el flujo de trabajo implementa un archivo de Bicep en el que se define una base de datos de Azure SQL y, después, se le 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