Vista previa y aprobación de la implementación

5 minutos

Ahora ha descubierto los trabajos de flujo de trabajo y cómo puede agregar un trabajo de flujo de trabajo para validar el código de Bicep. El siguiente paso para generar confianza con la implementación consiste en agregar otro trabajo a fin de comprobar exactamente qué cambiará la implementación.

En esta unidad, descubrirá cómo usar el comando what-if en un flujo de trabajo. También obtendrá información sobre cómo agregar reglas de protección del entorno para que tenga la oportunidad de comprobar manualmente la salida del comando antes de que se ejecute la implementación.

La operación hipotética

Un archivo de Bicep describe el estado en el que quiere que esté el entorno de Azure al final de una implementación. Al enviar una implementación, Azure Resource Manager cambia el entorno de Azure para que coincida con el estado que se describe en el archivo de Bicep.

Una implementación puede dar lugar a la implementación de nuevos recursos en el entorno o a la actualización de los recursos existentes. Cuando se ejecuta una implementación en modo completo, puede dar lugar incluso a la eliminación de los recursos existentes.

Cada vez que se crean, actualizan o eliminan recursos, existe el riesgo de que las cosas puedan cambiar de una manera inesperada. Un procedimiento recomendado consiste en agregar un paso adicional para comprobar qué se va a crear, actualizar y eliminar exactamente. Esta comprobación agrega valor al proceso de automatización. Cuando la implementación se realiza en un entorno de producción, es importante confirmar los cambios que se van a producir en el entorno.

Resource Manager proporciona la operación what-if, que puede ejecutar en el archivo de Bicep dentro del trabajo de canalización:

Diagrama de un flujo de trabajo en el que se incluyen trabajos Lint, Validación y Vista previa. El trabajo Vista previa ejecuta una operación what-if en Azure.

La acción arm-deploy admite el desencadenamiento de la operación what-if mediante la propiedad additionalArguments:

jobs:
  preview:
     runs-on: ubuntu-latest
     needs: [lint, validate]
     steps: 
     - 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
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
         template: deploy/main.bicep
         parameters: >
           environmentType=${{ env.ENVIRONMENT_TYPE }}
         additionalArguments: --what-if

El código resaltado equivale a ejecutar la implementación mediante la CLI de Azure, con el argumento --what-if incluido.

La operación hipotética no realiza ningún cambio en el entorno. En su lugar, describe los recursos que se crearán, las propiedades de recursos que se actualizarán y los recursos que se eliminarán.

La operación hipotética a veces muestra que un recurso cambiará cuando realmente no se va a producir ningún cambio. Este tipo de salida se denomina ruido. Trabajamos para reducir estos problemas, pero necesitamos su ayuda. Notificación de problemas con what-if.

Después de ver la salida de la operación what-if, puede determinar si se debe continuar con la implementación. Este paso suele implicar que una persona revise la salida del comando what-if y, después, tome una decisión sobre si los cambios identificados son razonables. Si un revisor decide que los cambios son razonables, puede aprobar manualmente la ejecución del flujo de trabajo.

Para obtener más información sobre el comando hipotético, vea el módulo de Microsoft Learn Vista previa de los cambios de implementación de Azure mediante el uso de hipótesis.

Entornos

En Acciones de GitHub, un entorno representa el lugar en el que se implementa la solución. Los entornos proporcionan características que facilitan el trabajo con implementaciones complejas. En un módulo posterior, obtendrá más información sobre los entornos y sus características. Por ahora, nos centraremos en su capacidad para agregar los revisores necesarios al flujo de trabajo.

Para crear un entorno, use la interfaz web de GitHub. Puede crear entornos cuando trabaje con un repositorio GitHub público o cuando use una cuenta de GitHub Enterprise.

Después de crear un entorno, puede hacer referencia a él en cualquier trabajo del flujo de trabajo:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: 'Lint Bicep template'
      run: az bicep build --file deploy/main.bicep

  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
        deploymentMode: Validate

  deploy:
    runs-on: ubuntu-latest
    environment: MyAzureEnvironment
    needs: [lint, validate]
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Nota:

Cuando la identidad de carga de trabajo del flujo de trabajo de implementación interactúa con Resource Manager dentro de un entorno, necesita una credencial federada configurada con el nombre del entorno. Aprenderá más sobre los entornos en módulos posteriores. Al ejecutar los ejercicios de este módulo, creará las credenciales federadas necesarias.

Reglas de protección del entorno

Después de crear un entorno, puede definir reglas de protección. Las reglas de protección se usan para comprobar las condiciones que se deben cumplir antes de que un paso pueda usar el entorno. La regla de protección de revisores obligatorios es un tipo de comprobación que requiere que una persona proporcione una aprobación manual.

Las reglas de protección se definen en el entorno, no en el flujo de trabajo. Los autores del archivo YAML del flujo de trabajo no pueden quitar ni agregar estas reglas de protección. Solo los administradores de un repositorio o el propietario de la cuenta pueden administrar entornos y sus reglas de protección.

Las reglas de protección del entorno ayudan a garantizar que las personas adecuadas estén implicadas en el proceso de implementación.

¿Cómo funcionan las reglas de protección del entorno?

Al asociar un entorno a un paso, las reglas de protección del entorno se evalúan justo antes de que comience el paso.

Un revisor obligatorio es un tipo de regla de protección. Al configurar una regla de protección de revisor obligatorio, asigna uno o varios usuarios de GitHub que necesitan aprobar la continuación del flujo de trabajo.

Los entornos también proporcionan otros tipos de reglas de protección. Por ejemplo, puede restringir las ramas de Git que se pueden implementar en entornos específicos. En este módulo solo se analiza la regla de revisores obligatorios, pero en el resumen se proporcionan vínculos para obtener más información sobre otras reglas de protección.

Una vez que el flujo de trabajo comienza y alcanza un paso que requiere un revisor, la ejecución del flujo de trabajo se pausa. A todos los usuarios designados como revisores se les envía un mensaje en GitHub y por correo electrónico.

Los revisores pueden inspeccionar los registros del flujo de trabajo como, por ejemplo, los cambios que detecta la operación what-if. En función de esta información, aprueban o rechazan el cambio. Si aprueban el cambio, se reanuda el flujo de trabajo. Si rechazan o no responden en el periodo de tiempo de espera, se produce un error en el trabajo.

Diagrama de un flujo de trabajo que incluye los trabajos Lint, Validación, Vista previa e Implementación, con una comprobación de aprobación antes del trabajo Implementación.

La importancia de los procedimientos recomendados

La característica de entornos de GitHub le ofrece la capacidad de vincular las implementaciones a un entorno y, después, la implementación hereda las reglas de protección que define el administrador del entorno. Pero no hay ningún requisito de que los nuevos flujos de trabajo usen entornos.

Es importante para una organización establecer procedimientos recomendados para revisar las definiciones de flujo de trabajo. Por ejemplo, configure el repositorio para requerir revisiones de solicitudes de cambios para cualquier cambio en la rama principal mediante reglas de protección de ramas. Obtendrá más información sobre este concepto en un módulo posterior.