Control de implementación de versiones mediante puertas

  • Artículo
  • Tiempo de lectura: 6 minutos
  • En el caso de las puertas previasa la implementación, el retraso sería el tiempo necesario para que todos los errores se registrarán en los artefactos que se implementan.
  • En el caso de las puertas posteriores a la implementación,el retraso sería el máximo del tiempo 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 los incidentes se registran después de la implementación.

Las siguientes puertas están disponibles de forma predeterminada:

  • Invocación de la función de Azure:desencadene la ejecución de una función de Azure y asegúrese de que se completa correctamente. Para más información, consulte Tarea de función de Azure.
  • Consultar alertas de Azure Monitor:observe las reglas de alertas de Azure Monitor configuradas para las alertas activas. Para más información, consulte Tarea de Azure Monitor.
  • Invocar API REST:realice una llamada a una API REST y continúe si devuelve una respuesta correcta. Para obtener más información, consulte Tarea de API DE REST HTTP.
  • Consultar elementos de trabajo:asegúrese de que el número de elementos de trabajo correspondientes devueltos por una consulta está dentro de un umbral. Para obtener más información, vea Tarea de consulta de elementos de trabajo.
  • Evaluación de seguridad y cumplimiento:evalúe Azure Policy cumplimiento de los recursos dentro del ámbito de una suscripción y un grupo de recursos determinados, y opcionalmente en un nivel de recurso específico. Para obtener más información, vea Security Compliance and Assessment task.

Puede crear sus propias puertas con extensiones de Marketplace.

Las opciones de evaluación que se aplican a todas las puertas que ha agregado son:

  • Tiempo entre la reevaluación de las puertas. Intervalo de tiempo entre las evaluaciones sucesivas de las puertas. En cada intervalo de muestreo, las nuevas solicitudes se envían simultáneamente a cada puerta y se evalúan los nuevos resultados. Se recomienda que el intervalo de muestreo sea mayor que el tiempo de respuesta típico más largo de las puertas configuradas para permitir que se reciban todas las respuestas para la evaluación.
  • Tiempo de espera después del cual se producirá un error en las puertas. Período máximo de evaluación para todas las puertas. La implementación se rechazará si se alcanza el tiempo de espera antes de que todas las puertas tengan éxito durante el mismo intervalo de muestreo.
  • Puertas y aprobaciones. Seleccione el orden de ejecución necesario para puertas y aprobaciones si ha configurado ambos. En el caso de las condiciones previas a la implementación, el valor predeterminado es solicitar primero las aprobaciones manuales (de usuario) y, después, evaluar las puertas. Esto hace que el sistema no evalúe las funciones de puerta si el usuario rechaza la versión. En el caso de las condiciones posteriores a la implementación, el valor predeterminado es evaluar las puertas y solicitar aprobaciones manuales solo cuando todas las puertas se han realizado correctamente. Esto garantiza que los aprobadores tengan toda la información necesaria para aprobar.

Para obtener información sobre cómo ver los resultados y los registros de la puerta, consulte Visualización de los registros para aprobaciones y Supervisión y seguimiento de implementaciones.

Ejemplos de flujo de evaluación de puertas

En el diagrama siguiente se muestra el flujo de evaluación de la puerta donde, después del período inicial de retraso de estabilización y tres intervalos de muestreo, se aprueba la implementación.

Puertas correctas

En el diagrama siguiente se muestra el flujo de evaluación de la puerta en el que, después del período inicial de retraso de estabilización, no todas las puertas se han instalado correctamente en cada intervalo de muestreo. En este caso, una vez expirado el período de tiempo de espera, se rechaza la implementación.

Puertas con errores

Vídeo

Recursos adicionales

Ayuda y soporte técnico

Azure Pipelines

Las puertas permiten la recopilación automática de señales de estado de los servicios externos y, a continuación, promueven la versión cuando todas las señales son correctas al mismo tiempo o detienen la implementación en tiempo de espera. Normalmente, las puertas se usan en relación con la administración de incidentes, la administración de problemas, la administración de cambios, la supervisión y los sistemas de aprobación externos.

Escenarios para puertas

Algunos escenarios y casos de uso para puertas son:

  • Administración de incidentes y problemas. Asegúrese del estado necesario para los elementos de trabajo, incidentes y problemas. Por ejemplo, asegúrese de que la implementación se produzca solo si no existe ningún error de prioridad cero y de que no se produzca ningún incidente activo después de la implementación.
  • Busque aprobaciones fuera Azure Pipelines. Notifique a los usuarios que no Azure Pipelines, como departamentos de aprobación legal, auditores o administradores de TI, una implementación mediante la integración con sistemas de colaboración de aprobación como Microsoft Teams o Slack, y esperando a que se complete la aprobación.
  • Validación de calidad. Consulte las métricas de las pruebas en los artefactos de compilación, como la velocidad de paso o la cobertura de código, e impleméntese solo si se encuentran dentro de los umbrales necesarios.
  • Examen de seguridad en artefactos. Asegúrese de que se han completado los exámenes de seguridad, como la comprobación antivirus, la firma de código y la comprobación de directivas para artefactos de compilación. Una puerta puede iniciar el examen y esperar a que se complete, o simplemente comprobar la finalización.
  • Experiencia del usuario con respecto a la línea de base. Con la telemetría del producto, asegúrese de que la experiencia del usuario no ha retrocedido del estado de línea base. El nivel de experiencia antes de la implementación podría considerarse una 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 que se produzca la implementación.
  • Estado de la infraestructura. Ejecute la supervisión y valide la infraestructura con las reglas de cumplimiento después de la implementación, o espere un uso correcto de los recursos y un informe de seguridad positivo.

La mayoría de los parámetros de mantenimiento varían con el tiempo, cambiando regularmente su estado de correcto a incorrecto y de vuelta a correcto. Para tener en cuenta estas variaciones, todas las puertas se reevaluan periódicamente hasta que todas se realizan correctamente al mismo tiempo. La ejecución e implementación de la versión no continúa si todas las puertas no se realizaron correctamente en el mismo intervalo y antes del tiempo de espera configurado.

Definición de una puerta para una fase

Puede habilitar puertas al principio de una fase (en las condiciones previas a la implementación)o al final de una fase(condicionesposteriores a la implementación), o ambas. Para obtener más información sobre cómo habilitar puertas, vea Configurar una puerta.

El retraso antes de la evaluación es un retraso de tiempo al principio del proceso de evaluación de la puerta que permite a las puertas inicializar, estabilizar y empezar a proporcionar resultados precisos para la implementación actual (vea Flujosde evaluación de la puerta ). Por ejemplo: