Conceptos de puertas de despliegue
Azure DevOps Services | Azure DevOps Server 2022: Azure DevOps Server 2019
Las puertas de implementación en Azure Pipelines se añaden a las pipelines de lanzamiento para garantizar que los implementaciones cumplen criterios específicos antes de continuar. Las puertas son esenciales para garantizar que las implementaciones sean fiables y seguras, ya que imponen comprobaciones rigurosas que conducen a implantaciones de software más estables y seguras.
Las puertas se definen en las condiciones previas y posteriores a la implementación de una fase de lanzamiento. Proporcionan un mecanismo para recopilar automáticamente señales de estado de servicios externos, como Azure Functions o LAS API REST, para controlar la promoción de versiones basadas en estas señales. Las puertas trabajan con las aprobaciones para garantizar que las partes interesadas adecuadas aprueban la versión y que esta cumple los criterios de calidad y conformidad necesarios.
Casos de uso
Algunos casos de uso comunes para las puertas de implementación son:
- administración de incidentes: asegúrese de que se cumplen determinados criterios antes de continuar con la implementación. Por ejemplo, asegúrese de que la implementación solo se produce si no existe ningún error de prioridad cero.
- Buscar aprobaciones: integrar con Microsoft Teams o Slack para notificar a usuarios externos, como auditores, o administradores de TI sobre una implementación y esperar sus aprobaciones.
- Validación de calidad: consulte las métricas de canalización, como la tasa de aprobación o la cobertura de código, e impleméntelas solo si están dentro de un umbral predefinido.
- Examen de seguridad: realice comprobaciones de seguridad como el examen de artefactos, la firma de código y la comprobación de directivas. Una puerta de implementación puede iniciar el escaneo y esperar a que se complete, o simplemente verificar su finalización.
- Experiencia del usuario en relación con la línea de base: utilice la colección de datos del producto para garantizar que la experiencia del usuario retrocede con respecto al estado de referencia. Las métricas de la experiencia del usuario antes de que la implementación se pudieran usar como línea base.
- administración de cambios: espere a que se completen los procedimientos de administración de cambios en un sistema como ServiceNow antes de continuar con la implementación.
- Estado de la infraestructura: Ejecute el monitoreo y valide la infraestructura con respecto a las reglas de cumplimiento después de la implementación, o espere a una utilización adecuada de los recursos y un informe de seguridad positivo.
La mayoría de los parámetros de salud varían con el tiempo, cambiando periódicamente su estado de saludable a no saludable y de vuelta a saludable. Para tener en cuenta estas variaciones, todas las compuertas se reevaluan periódicamente hasta que todas funcionen al mismo tiempo. La ejecución e implementación de versiones no continúa si todas las validaciones no han tenido éxito en el mismo intervalo y antes del tiempo de espera configurado.
Definición de una validación para una fase
Puede habilitar las puertas al principio de una fase (condiciones de implementación previa) o al final de una fase (condiciones posteriores a la implementación) o para ambas. Para obtener más información, consulte Configuración de puertas.
El retraso antes de la evaluación es un retraso al principio del proceso de evaluación de la validación que permite que las validaciones se inicialicen, estabilicen y comiencen a proporcionar resultados precisos para la implementación actual. Para obtener más información, consulte Flujos de evaluación de puertas.
- En las validaciones previas a la implementación, el retraso sería el tiempo necesario para que todos los errores se registren en los artefactos que se implementan.
- En las validaciones posteriores a la implementación, el retraso sería el tiempo máximo necesario para que la aplicación implementada alcance un estado operativo estable, el tiempo necesario para la ejecución de todas las pruebas necesarias en la fase implementada y el tiempo necesario para que se registren incidentes después de la implementación.
Las siguientes puertas están disponibles de forma predeterminada:
- Invocar la función de Azure: desencadene la ejecución de una función de Azure y asegúrese de que se complete correctamente. Para obtener más información, consulte Tarea de función de Azure.
- Consulte las alertas de Azure Monitor: observe las reglas de alerta de Azure monitor configuradas para las alertas activas. Para obtener más información, consulte la tarea de Azure Monitor.
- invocar la API REST: realice una llamada a una API REST y continúe si devuelve una respuesta correcta. Para más información,vea Tarea Invocación de REST API.
- Consulta de elementos de trabajo: asegúrese de que el número de elementos de trabajo coincidentes devueltos desde una consulta está dentro de un umbral. Para obtener más información, consulte Tarea de monitorización de Azure.
- Comprobación del cumplimiento de Azure Policy: evaluación del cumplimiento de Azure Policy en los recursos dentro del ámbito de una suscripción y un grupo de recursos determinado, y opcionalmente en un nivel de recurso específico. Para más información, consulte la tarea de comprobación del cumplimiento de las políticas de Azure .
También puede crear sus propias puertas con extensiones de Marketplace.
Las opciones de evaluación que se aplican a todas las puertas son:
- El tiempo entre la reevaluación de las validaciones. Intervalo de tiempo entre evaluaciones sucesivas de las validaciones. En cada intervalo de muestreo, las nuevas solicitudes se envían simultáneamente a cada puerta y se evalúan los nuevos resultados. La recomendación es que el intervalo de muestreo sea mayor que el tiempo de respuesta típico más largo de las puertas configuradas para permitir que todas las respuestas se reciban para su evaluación.
- El tiempo de espera tras el cual se produce un error de las validaciones. Período de evaluación máximo de todas las validaciones. La implementación se rechaza si se alcanza el tiempo de espera antes de que todas las validaciones se realicen correctamente durante el mismo intervalo de muestreo.
- Validaciones y aprobaciones. Seleccione el orden de ejecución necesario para las validaciones y aprobaciones si ha configurado ambos. En el caso de las condiciones previas a la implementación, el valor predeterminado es solicitar primero aprobaciones manuales (usuario) y luego evaluar las puertas, evitando así que el sistema evalúe las funciones de las puertas si el usuario rechaza la versión. Para las condiciones posteriores a la implantación, el valor predeterminado es evaluar las puertas y solicitar aprobaciones manuales solo cuando todas las puertas se han realizado correctamente, lo que garantiza que los aprobadores disponen de toda la información necesaria para aprobar la versión.
Para obtener más información sobre el análisis de puertas, consulte Ver registros de aprobaciones y Supervisar y realizar un seguimiento de las implantaciones.
Ejemplos de flujo de evaluación de validaciones
En el diagrama siguiente se muestra el flujo de evaluación de la puerta donde, después del período de retraso de estabilización inicial y tres intervalos de muestreo, se aprueba la implementación.
En el siguiente diagrama se ilustra el flujo de evaluación de puertas, donde después del período inicial de retraso de estabilización, no todas las puertas tuvieron éxito en cada intervalo de muestreo. En este caso, después de que expire el período de tiempo de espera, se rechaza la implementación.
