Vista previa y aprobación de la implementación

Completado

Ya ha obtenido información sobre las fases de canalización y cómo puede agregar una para validar el código de Bicep. El siguiente paso para generar confianza con la implementación consiste en agregar otra fase a fin de comprobar exactamente qué cambiará la implementación.

En esta unidad, aprenderá a usar el comando hipotético en una canalización. También aprenderá a agregar aprobaciones 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.

Cuando 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é recursos se van a crear, actualizar y eliminar. 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 hipotética, que puede ejecutar en el archivo de Bicep dentro de la fase de canalización:

Puede usar el comando az deployment group what-if de la CLI de Azure desde dentro de la definición de canalización para ejecutar el paso hipotético:

stages:

- stage: Preview
  jobs: 
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

Sugerencia

En este módulo, usaremos la CLI de Azure para la operación hipotética. Si crea una canalización propia basada en PowerShell, puede usar el cmdlet New-AzResourceGroupDeployment con el modificador -Whatif, o bien usar el cmdlet Get-AzResourceGroupDeploymentWhatIfResult.

La operación hipotética no realiza ningún cambio en el entorno. En su lugar, describe los recursos que se crearán o eliminará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. Estos comentarios se llaman ruido. Trabajamos para reducir estos problemas, pero necesitamos su ayuda para notificarlos.

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 de canalización.

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 Azure Pipelines, 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, se centrará en su capacidad para agregar aprobaciones manuales a la canalización.

Como ya sabe, los trabajos se usan para definir una secuencia de pasos dentro de una fase de canalización. Al incluir entornos en la canalización, debe usar un tipo especial de trabajo denominado trabajo de implementación. Un trabajo de implementación es similar a un trabajo normal, pero proporciona cierta funcionalidad adicional. Esta funcionalidad incluye la definición del entorno que usa el trabajo de implementación:

variables:
  - name: deploymentDefaultLocation
    value: westus3

stages:

- stage: Preview
  jobs:
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

- stage: Deploy
  jobs:
    - deployment: Deploy
      environment: MyAzureEnvironment
      strategy:
        runOnce:
          deploy:
            steps:
            - checkout: self

            - task: AzureResourceManagerTemplateDeployment@3
              name: Deploy
              displayName: Deploy to Azure
              inputs:
                connectedServiceName: 'MyServiceConnection'
                location: $(deploymentDefaultLocation)
                resourceGroupName: $(ResourceGroupName)
                csmFile: deploy/main.bicep

Observe que en la definición de YAML para un trabajo de implementación hay algunas diferencias clave con respecto a un trabajo normal:

• En lugar de comenzar con la palabra job, un trabajo de implementación se define como deployment.
• La palabra clave environment especifica el nombre del entorno de destino. En el ejemplo anterior, se realiza el seguimiento de la implementación en un entorno denominado MyAzureEnvironment.
• La palabra clave strategy especifica cómo ejecuta Azure Pipelines los pasos de implementación. Las estrategias de implementación admiten procesos de implementación complejos, especialmente si tiene varios entornos de producción. En este módulo, se usa la estrategia de implementación runOnce. Esta estrategia se comporta de forma similar a otros trabajos a los que ya está acostumbrado.

Comprobaciones y aprobaciones de fase

Después de crear un entorno, puede definir comprobaciones. Las comprobaciones se usan para comprobar las condiciones que se deben cumplir antes de que una canalización pueda usar el entorno. Una aprobación es un tipo de comprobación en la que es necesario que una persona proporcione una aprobación manual.

Las comprobaciones se definen en el entorno, no en la canalización. Los creadores del archivo YAML de canalización no pueden quitar ni agregar estas comprobaciones y aprobaciones. Solo los administradores de un entorno pueden administrar las aprobaciones y comprobaciones en él.

En muchas organizaciones, el propietario de un entorno de Azure Pipelines es la persona responsable del entorno en el que se implementa. Las comprobaciones y aprobaciones ayudan a garantizar que las personas adecuadas estén implicadas en el proceso de implementación.

¿Cómo funcionan las comprobaciones y aprobaciones?

Las aprobaciones y comprobaciones se evalúan justo antes de que comience una fase de canalización. Cuando Azure Pipelines está a punto de ejecutar una fase de canalización, examina todos los recursos de canalización que usa la fase, incluidos los entornos. Los entornos pueden tener comprobaciones que se deben satisfacer.

Una aprobación es un tipo de comprobación. Al configurar una comprobación de aprobación, se asignan uno o varios usuarios que necesitan aprobar la continuación de la canalización.

Azure Pipelines también proporciona otros tipos de comprobaciones. Por ejemplo, puede llamar a una API para ejecutar lógica personalizada, controlar el horario comercial durante el que se puede ejecutar una fase e incluso consultar Azure Monitor para asegurarse de que una implementación se ha ejecutado correctamente. En este módulo solo se describirán las comprobaciones de aprobación, pero en el resumen se proporcionan vínculos a más información sobre las comprobaciones.

Nota:

En los grupos de agentes y las conexiones de servicio también se pueden configurar comprobaciones. También puede usar un paso especial denominado tarea de aprobación manual. Pero en este módulo se centrará en los entornos y las comprobaciones asociadas a ellos.

Una vez que la canalización comienza y alcanza una fase en la que se necesita una comprobación de aprobación, la ejecución de canalización se detiene. A todos los usuarios que se han designado como aprobadores se les envía un mensaje en Azure DevOps y por correo electrónico.

Los aprobadores pueden inspeccionar los registros de canalización, por ejemplo, los cambios que detecta la operación hipotética. En función de esta información, aprueban o rechazan el cambio. Si aprueban el cambio, la canalización se reanuda. Si lo rechazan, o si no responden dentro de un período de tiempo de espera configurable, se produce un error en la fase.

La importancia de los procedimientos recomendados

La característica de entornos de Azure Pipelines proporciona la capacidad de vincular las implementaciones a un entorno y, después, la implementación hereda las aprobaciones y comprobaciones definidas por el propietario del entorno. Pero no hay ningún requisito de que las nuevas canalizaciones usen entornos.

Es importante que usted y la organización establezcan procedimientos recomendados para revisar las definiciones de canalización. Un ejemplo consiste en configurar el repositorio para exigir revisiones de solicitudes de incorporación de cambios en cualquier cambio en la rama principal mediante directivas de protección de rama. Obtendrá más información sobre este concepto en un módulo posterior.

También puede agregar comprobaciones y aprobaciones a las conexiones de servicio que garantizan que la aprobación se obtenga antes de que una implementación pueda usar las credenciales de una entidad de servicio. Pero las aprobaciones también afectarían a la capacidad de la canalización para ejecutar la validación preparatoria y la operación hipotética, ya que también necesitan una conexión de servicio.

Podría usar otro servicio independiente para la fase hipotética con una entidad de servicio propia. La entidad de servicio que se usa para las fases preparatoria y de validación debe tener definido un rol personalizado de Azure, para asegurarse de que tiene los permisos mínimos que necesita para realizar su trabajo.