Definición de aprobaciones y comprobaciones

Azure DevOps Services

Una canalización consta de varias fases. Un autor de canalización puede controlar si una fase debe ejecutarse definiendo condiciones en la fase. Otra manera de controlar si y cuándo se debe ejecutar una fase es a través de aprobaciones y comprobaciones.

Las aprobaciones y otras comprobaciones no se definen en el archivo yaml. Los usuarios que modifican el archivo yaml de canalización no pueden modificar las comprobaciones realizadas antes del inicio de una fase. Los administradores de recursos administran comprobaciones mediante la interfaz web de Azure Pipelines.

Las canalizaciones se basan en recursos como entornos, conexiones de servicio, grupos de agentes, grupos de variables y archivos seguros. Las comprobaciones permiten al propietario del recurso controlar si y cuándo una fase de cualquier canalización puede consumir un recurso. Como propietario de un recurso, puede definir comprobaciones que deben cumplirse antes de que se pueda iniciar una fase que consuma ese recurso. Por ejemplo, una comprobación de aprobación manual en un entorno garantiza que la implementación en ese entorno solo se produzca después de que los usuarios designados hayan revisado los cambios que se implementan.

Una fase puede constar de muchos trabajos y cada trabajo puede consumir varios recursos. Para que se pueda iniciar la ejecución de una fase, se deben cumplir todas las comprobaciones de todos los recursos usados en esa fase. Azure Pipelines pausa la ejecución de una canalización antes de cada fase y espera a que se completen todas las comprobaciones pendientes.

Hay cinco categorías de aprobaciones y comprobaciones y se ejecutan en el orden en que se crearon dentro de cada categoría. Las comprobaciones se vuelven a evaluar en función del intervalo de reintento especificado en cada comprobación. Si todas las comprobaciones no se realizan correctamente hasta que se haya especificado el tiempo de espera, esa fase no se ejecuta. Si se produce un error en alguna de las comprobaciones de forma terminal (por ejemplo, si rechaza una aprobación en uno de los recursos) esa fase no se ejecuta.

Puede volver a intentar una fase cuando se agote el tiempo de espera de las aprobaciones y comprobaciones.

Las comprobaciones estáticas se ejecutan primero y, a continuación, se ejecutan las aprobaciones de comprobación previa. Las categorías por orden son:

1. Comprobaciones estáticas: control de rama, plantilla requerida y evaluar artefacto
2. Aprobaciones previas a la comprobación
3. Comprobaciones dinámicas: aprobación, invocar la función de Azure, invocar la API REST, horas laborables, consulta de alertas de Azure Monitor
4. Aprobaciones posteriores a la comprobación
5. Bloqueo exclusivo

También puede ver el orden de ejecución en la pestaña Aprobaciones y comprobaciones.

Importante

Las comprobaciones se pueden configurar en entornos, conexiones de servicio, repositorios, grupos de variables, archivos seguros y grupos de agentes.

Las conexiones de servicio no se pueden especificar mediante variable.

Aprobaciones

Puede controlar manualmente cuándo se debe ejecutar una fase mediante aprobaciones y comprobaciones. Esta comprobación se usa normalmente para controlar las implementaciones en entornos de producción.

1. Inicie sesión en su organización de Azure DevOps y vaya a su proyecto.

2. Seleccione Canalizaciones>Entornos y luego seleccione su entorno.

3. Seleccione la pestaña Aprobaciones y comprobaciones y, a continuación, seleccione el signo + para agregar una nueva comprobación.

   

4. Seleccione Aprobaciones y, a continuación, Siguiente.

5. Agregue usuarios o grupos como aprobadores designados y, si lo desea, proporcione instrucciones para los aprobadores. Especifique si desea permitir o restringir que los aprobadores aprueben sus propias ejecuciones y especifique el tiempo de expiración deseado. Si las aprobaciones no se completan dentro del tiempo de expiración especificado, la fase se marca como omitida.

6. Seleccione Crear cuando haya terminado.

   

7. Una vez desencadenada la comprobación de aprobación, se presenta una ventana de consulta, como se muestra en el ejemplo siguiente, en la interfaz de usuario. Esta ventana proporciona la opción de que los aprobadores rechacen o aprueben la ejecución, junto con las instrucciones complementarias.

   

La lista de usuarios que pueden revisar una aprobación se fija en el momento en que las aprobaciones y comprobaciones comienzan a ejecutarse. Es decir, no se seleccionan los cambios en la lista de usuarios y grupos de una comprobación de aprobación realizada después de que las comprobaciones empiecen a ejecutarse.

Nota:

Si un grupo se designa como aprobador, solo un usuario del grupo debe aprobar la ejecución para continuar.

Aprobaciones diferidas

Hay situaciones en las que la hora en que se da una aprobación y la hora a la que debe comenzar la implementación no coinciden. Por ejemplo, puede que quiera esperar a implementar una nueva versión hasta una hora de poco tráfico por la tarde.

Para hacer frente a esta situación, puede aplazar una aprobación y fijar el momento en que se hará efectiva.

1. Seleccione Aplazar aprobación.

   

2. Establezca la hora de aprobación.

   

Verá la aprobación en el panel Comprobaciones como una aprobación previa. La aprobación es efectiva a la hora fijada.

Control de rama

Con la comprobación de control de rama, puede asegurarse de que todos los recursos vinculados a la canalización se compilan a partir de las ramas permitidas y de que las ramas tienen habilitada la protección. Esta comprobación ayuda a controlar la preparación de la versión y la calidad de las implementaciones. En caso de que se vinculen varios recursos con la canalización, se comprueba el origen de todos ellos. Si ha vinculado otra canalización, la rama de la ejecución específica que se está implementando se comprueba para la protección.

Para definir la comprobación del control de rama:

1. En el proyecto de Azure DevOps, vaya al recurso (por ejemplo, al entorno) que se va a proteger.

2. Vaya a Aprobaciones y comprobaciones en el recurso.

3. Elija la comprobación de control Rama y proporcione una lista separada por comas de ramas permitidas. Puede exigir que la rama tenga habilitada la protección. También puede definir el comportamiento de la comprobación si no se conoce el estado de protección de una de las ramas. Una rama se considera protegida si se ha aplicado al menos una directiva (incluidas las directivas aplicadas en el nivel de repositorio).

   

En el tiempo de ejecución, la comprobación validaría las ramas de todos los recursos vinculados de la ejecución en la lista de permitidos. Si alguna de las ramas no coincide con los criterios, se produce un error en la comprobación y la fase se marca como errónea.

Nota:

La comprobación requiere que los nombres de rama estén completos. Asegúrese de que el formato del nombre de la rama sea refs/heads/<branch name>

Horario laboral

En caso de que quiera que todas las implementaciones en el entorno se produzcan solo en un período de tiempo específico, la comprobación del horario comercial es la solución ideal. Al ejecutar una canalización, la ejecución de la fase que usa el recurso espera horas laborables. Si tiene varias ejecuciones ejecutándose simultáneamente, cada una de ellas se comprueba de forma independiente. Al principio del horario comercial, la comprobación se marca como correcta para todas las ejecuciones.

Si la ejecución de la fase no se ha iniciado al final del horario comercial (mantenida por alguna otra comprobación), la aprobación del horario comercial se retira automáticamente y se programa una reevaluación que se llevará a cabo el día siguiente. Se produce un error en la comprobación si la ejecución de la fase no se inicia dentro del período de tiempo de espera especificado para la comprobación y, por lo tanto, la fase se marca como errónea.

Invocar función de Azure

Azure Functions es la plataforma de cálculo sin servidor que ofrece Azure. Con Azure Functionspuede ejecutar pequeños fragmentos de código (denominados "funciones"), por lo que no necesita preocuparse por la infraestructura de la aplicación. Dada la alta flexibilidad, Azure Functions proporciona una excelente manera de crear sus propias comprobaciones. Incluya la lógica de la función de inserción en el repositorio de Azure para que cada ejecución se desencadene en la solicitud http, tenga un breve tiempo de ejecución y devuelva una respuesta. Al definir la comprobación, puede analizar el cuerpo de la respuesta para deducir si la comprobación se realiza correctamente. La evaluación se puede repetir periódicamente con la opción Tiempo entre evaluaciones en las opciones de control. Más información

Si la comprobación no se realiza de forma correcta en el tiempo de espera configurado, se omite la fase asociada. También se omiten las fases que dependen de ella. Para más información, vea la Tarea Aplicación de funciones de Azure.

Nota:

Las variables de canalización definidas por el usuario son accesibles para la comprobación a partir de Sprint 215.

Lea más información sobre la manera recomendada de usar las comprobaciones de invocación de Azure Function. Para ser compatibles, las comprobaciones deben seguir reglas específicas según su modo y el número de reintentos.

Invocar API REST

La comprobación de la API REST de invocación le permite integrarse con cualquiera de los servicios existentes. Invocar API REST: llame a una API REST y continúe si devuelve una respuesta correcta. Más información

La evaluación se puede repetir periódicamente con la opción Tiempo entre evaluaciones en las opciones de control. Si la comprobación no se realiza de forma correcta en el tiempo de espera configurado, se omite la fase asociada. También se omiten las fases que dependen de ella. Para más información,vea Tarea Invocación de REST API.

Nota:

Las variables de canalización definidas por el usuario son accesibles para la comprobación a partir de Sprint 215.

Obtenga más información sobre la manera recomendada de usar las comprobaciones de invocación de API de REST.

Consultar las alertas de Azure Monitor

Azure Monitor ofrece funciones de visualización, consulta, enrutamiento, alertas, escalado automático y automatización de los datos tanto de la infraestructura de Azure como de cada recurso individual de Azure. Las alertas son un medio estándar para detectar problemas con el estado de la infraestructura o la aplicación y tomar medidas correctivas. Las implementaciones controladas y los lanzamientos preconfigurados son estrategias de implementación comunes que se usan para reducir el riesgo de regresiones a aplicaciones críticas. Después de realizar la implementación en una fase (conjunto de clientes), se observa la aplicación durante un período de tiempo. El estado de la aplicación después de la implementación se usa para decidir si la actualización se debe realizar en la siguiente fase o no.

Consultar alertas de Azure Monitor ayuda a observarlo y a asegurarse de que no se generan alertas para la aplicación después de una implementación. La comprobación se realiza correctamente si no se activa ninguna regla de alerta en el momento de la evaluación. Más información

La evaluación se repite después del valor Tiempo entre evaluaciones en las opciones de control. Se produce un error en las comprobaciones si la fase no ha iniciado la ejecución dentro del período de tiempo de espera especificado.

Plantilla necesaria

Con la comprobación de plantilla necesaria, puede aplicar canalizaciones para usar una plantilla YAML específica. Cuando se ha implementado esta comprobación, se produce un error en una canalización si no se extiende desde la plantilla a la que se hace referencia.

Para definir una aprobación de plantilla necesaria:

1. En el proyecto de Azure DevOps, vaya a la conexión de servicio que desea restringir.

2. Abra Aprobaciones y comprobaciones en el menú situado junto a Editar.

3. En el menú Agregar la primera comprobación, seleccione Plantilla requerida.

4. Escriba los detalles sobre cómo llegar al archivo de plantilla necesario.

   • Tipo de repositorio: la ubicación del repositorio (GitHub, Azure o Bitbucket).
   • Repositorio: el nombre del repositorio que contiene la plantilla.
   • Ref: la rama o etiqueta de la plantilla necesaria.
   • Ruta de acceso a la plantilla necesaria: el nombre de la plantilla.

Puede tener varias plantillas necesarias para la misma conexión de servicio. En este ejemplo, la plantilla necesaria es production_template.yaml.

Deshabilitación de una comprobación

Al depurar una comprobación, es posible que quiera deshabilitarla temporalmente y volverla a habilitar después. Para deshabilitar o habilitar una comprobación:

1. En el proyecto de Azure DevOps, vaya al recurso con una comprobación.

2. Abra la pestaña Aprobaciones y comprobaciones.

3. En el menú contextual, seleccione Deshabilitar o Habilitar.

   

Omitir una comprobación

En algunas circunstancias, como una implementación de reparaciones, es posible que tenga que omitir una comprobación. Solo puede omitir una comprobación si tiene el permiso de administrador para el recurso donde se define la comprobación.

Para omitir una aprobación, horarios comerciales, invocar Azure Function o invocar la comprobación de la API de REST, seleccione Omitir comprobación cuando el recurso esté esperando la revisión. Este es un ejemplo de omitir la comprobación del horario comercial.

Al omitir una comprobación, verá quién omite la comprobación en el panel de comprobaciones.

Evaluar el artefacto

Puede evaluar los artefactos que se van a implementar en un entorno en función de las políticas personalizadas.

Nota:

Actualmente, esto solo funciona con artefactos de imagen de contenedor

Para definir una evaluación de directiva personalizada sobre los artefactos, siga estos pasos.

1. En el proyecto de Azure DevOps Services, vaya al entorno que se va a proteger. Obtener más información sobre crear un entorno.

   

2. Vaya a Aprobaciones y comprobaciones en el entorno.

   

3. Seleccione Evaluar artefacto.

   

4. Pegue la definición de directiva y seleccione Guardar. Obtenga más información sobre cómo escribir definiciones de directiva.

   

Cuando se ejecuta una canalización, esa ejecución se pausa antes de entrar en una fase que usa el entorno. La directiva especificada se evalúa con los metadatos de imagen disponibles. La comprobación se supera cuando la directiva se realiza correctamente o cuando se produce un error. La fase se marca como fallida si se produce un error en la comprobación.

Superado

También puede ver los registros completos de las comprobaciones de directiva desde la vista de canalización.

Erróneo

También puede ver los registros completos de las comprobaciones de directiva desde la vista de canalización.

Bloqueo exclusivo

La comprobación de bloqueo exclusivo permite que solo continúe una ejecución del pipeline y se puede establecer en el nivel de etapa o pipeline. Todas las fases de todas las ejecuciones de esa canalización que usan el recurso se pausan. Cuando se complete la fase con el bloqueo, otra fase puede continuar con el uso del recurso. Además, solo se permite continuar una fase.

La propiedad lockBehavior determina cómo controlan otras fases los bloqueos. Cuando se especifica la propiedad lockBehavior de una fase, se crea automáticamente un bloqueo para esa fase. Hay dos valores lockBehavior posibles:

• runLatest - Solo la ejecución más reciente adquiere el bloqueo en el recurso. runLatest es el valor predeterminado si lockBehavior no se especifica.
• sequential - Todas las ejecuciones adquieren el bloqueo en el recurso protegido secuencialmente.

Para usar una comprobación de bloqueo exclusiva con implementaciones sequential o runLatest, siga estos pasos:

1. Habilite la comprobación de bloqueo exclusiva en el entorno (o en otro recurso protegido). La opción de bloqueo exclusivo es una comprobación disponible.

   

2. En el archivo YAML de la canalización, especifique una propiedad denominada lockBehavior. Esto se puede especificar para toda la canalización o para una fase determinada:

Se establece en una fase:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Se establece en la canalización:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Si no especifica un lockBehavior y se establece un bloqueo en un recurso, se usa el valor predeterminado de runLatest .

ServiceNow Change Management

Esta comprobación necesita que se instale la extensión ServiceNow Change Management desde Marketplace

La comprobación de ServiceNow Change Management permite una integración del proceso de ServiceNow Change Management en las canalizaciones. Al agregar la comprobación, se puede crear automáticamente una nueva solicitud de cambio en ServiceNow al principio de la fase. La canalización espera a que se complete el proceso de cambio antes de iniciar la fase. Aquí encontrará más detalles al respecto.

Varias aprobaciones y comprobaciones

Una fase puede constar de muchos trabajos y cada trabajo puede consumir varios recursos. Para que se pueda iniciar la ejecución de una fase, se deben cumplir todas las comprobaciones de todos los recursos usados en esa fase. Azure Pipelines pausa la ejecución de una canalización antes de cada fase y espera a que se completen todas las comprobaciones pendientes.

Una única decisión negativa final hace que se deniegue el acceso a la canalización y se produzca un error en la fase. Las decisiones de todas las aprobaciones y comprobaciones, excepto la invocación de Azure Function o la API de REST y el bloqueo exclusivo son definitivas. Puede volver a ejecutar correctamente la invocación de Azure Function o comprobaciones de API de REST.

Cuando se utilizan las comprobaciones de invocación de Azure Function o de API de REST de la forma recomendada, las decisiones de acceso también son definitivas.

Al especificar el tiempo entre evaluaciones para una comprobación de invocación de Azure Function o de API de REST para que no sea cero, la decisión de la comprobación no es definitiva. Merece la pena explorar este escenario.

Veamos un ejemplo. Imagine que la canalización de YAML tiene una fase que usa una conexión de servicio. Esta conexión de servicio tiene dos comprobaciones configuradas para ella:

1. Una comprobación asincrónica, denominada Aprobación externa concedida, que comprueba que se proporciona una aprobación externa y se configura de la manera recomendada.
2. Una comprobación sincrónica, denominada Motivo de implementación válido, que comprueba que el motivo de implementación es válido y para el que se establece el tiempo entre evaluaciones en 7 minutos.

En el diagrama siguiente se muestra una posible ejecución de comprobaciones.

En esta ejecución:

• Ambas comprobaciones, la aprobación externa concedida y el motivo de implementación válido, se invocan al mismo tiempo. El motivo de implementación válido produce un error inmediatamente, pero dado que la aprobación externa concedida está pendiente, se vuelve a intentar.
• En el minuto 7, se reintenta el motivo de implementación válido y, en esta ocasión, pasa.
• En el minuto 15, la aprobación externa concedida vuelve a recurrir a Azure Pipelines con una decisión correcta. Ahora, que ambas comprobaciones pasan, la canalización puede seguir implementando la fase.

Veamos otro ejemplo que implica dos comprobaciones sincrónicas. Imagine que la canalización de YAML tiene una fase que usa una conexión de servicio. Esta conexión de servicio tiene dos comprobaciones configuradas para ella:

1. A la comprobación sincrónica, denominada Sync Check 1, se le establece el tiempo entre evaluaciones en 5 minutos.
2. A la comprobación sincrónica, denominada Sync Check 2, se le establece el tiempo entre evaluaciones en 7 minutos.

En el diagrama siguiente se muestra una posible ejecución de comprobaciones.

En esta ejecución:

• Ambas comprobaciones, Sync Check 1 y Sync Check 2, se invocan al mismo tiempo. Sync Check 1 pasa, pero se vuelve a intentar, porque se produce un error en Sync Check 2.
• Al minuto 5, se reintenta Sync Check 1 , pero se produce un error, por lo que se vuelve a intentar.
• Al minuto 7, se reintenta Sync Check 2 y se realiza correctamente. La decisión de aprobación es válida durante 7 minutos. Si Sync Check 1 no pasa este intervalo de tiempo, se vuelve a intentar Sync Check 2.
• Al minuto 10, se reintenta Sync Check 1 , pero se produce un error, por lo que se vuelve a intentar.
• Al minuto 14, se reintenta Sync Check 2 y se realiza correctamente. La decisión de aprobación es válida durante 7 minutos. Si Sync Check 1 no pasa este intervalo de tiempo, se vuelve a intentar Sync Check 2.
• Al minuto 15, se reintenta Sync Check 1 y se realiza correctamente. Ahora, que ambas comprobaciones pasan, la canalización puede seguir implementando la fase.

Veamos un ejemplo que implica una comprobación sincrónica y una aprobación. Imagine que ha configurado una comprobación sincrónica y una aprobación para una conexión de servicio con un tiempo entre las evaluaciones de 5 minutos. Hasta que se dé la aprobación, la comprobación se ejecuta cada 5 minutos, independientemente de la decisión.

Preguntas más frecuentes

Las comprobaciones definidas no se iniciaron. ¿Qué ha ocurrido?

La evaluación de las comprobaciones se inicia una vez cumplidas las condiciones de la fase. Debe confirmar que la ejecución de la fase se ha iniciado después de agregar las comprobaciones en el recurso y que este se utiliza en la fase.

¿Cómo puedo usar comprobaciones para programar una fase?

Con la comprobación del horario comercial, puede controlar la hora de inicio de la ejecución de la fase. Puede lograr el mismo comportamiento que la programación predefinida en una fase de las versiones del diseñador.

¿Cómo puedo tomar aprobaciones anticipadas para una fase programada para ejecutarse en el futuro?

Este escenario se puede habilitar.

1. La comprobación del horario comercial permite que todas las fases de implementación en un recurso se programen para su ejecución entre el período de tiempo
2. Cuando las aprobaciones se configuran en el mismo recurso, la fase esperaría a recibir las aprobaciones para comenzar.
3. Puede configurar ambas comprobaciones en un recurso. La fase esperaría las aprobaciones y el horario comercial. Se iniciaría en la siguiente ventana programada una vez completadas las aprobaciones.

¿Puedo esperar a que finalice el examen de seguridad en el artefacto que se va a implementar?

Para esperar a que finalice el examen de seguridad en el artefacto que se va a implementar, deberá usar un servicio de análisis externo como AquaScan. El artefacto que se va a implementar debe cargarse en una ubicación accesible para el servicio de examen antes del inicio de las comprobaciones y se puede identificar mediante variables predefinidas. Con la comprobación Invocar API REST, puede agregar una comprobación para esperar en la API en el servicio de seguridad y pasar el identificador de artefacto como entrada.

¿Cómo puedo usar variables de salida de las fases anteriores en una comprobación?

De forma predeterminada, solo las variables predefinidas están disponibles para las comprobaciones. Puede usar un grupo de variables vinculado para acceder a otras variables. La variable de salida de la fase anterior se puede escribir en el grupo de variables y se puede acceder a ella en la comprobación.

Saber más

• Comprobaciones de Invocar función de Azure / API REST
• API REST de Aprobaciones y comprobaciones
• API REST de consulta de aprobaciones