Evaluación de la preparación previa al despliegue

Antes de que se cree una solicitud de cambio, la canalización calcula la disponibilidad de despliegue y establece el indicador DEPLOYMENT_READY en true o false. Esta bandera se deriva de las pruebas recogidas en las fases de IC y DC. Si alguna comprobación de pruebas indica una desviación, o una comprobación, escaneado o prueba fallida o ausente relacionada con el conjunto de artefactos desplegados, DEPLOYMENT_READY se establece en false.

La solicitud de cambio se prepara con los siguientes campos procedentes del último PR de promoción fusionado con la rama de destino:

• risk
• impact
• priority
• assignee
• description
• purpose
• customer impact
• deployment impact
• backout plan

Creación de solicitudes de cambio

La solicitud de modificación preparada se presenta en uno de los dos estados iniciales en función de DEPLOYMENT_READY:

El sistema de gestión de cambios también aprueba automáticamente las solicitudes de cambio cuando la implantación no causa ningún tiempo de inactividad (la duración de la interrupción es cero) y DEPLOYMENT_READY es true, y el riesgo de implantación está dentro de unos límites aceptables.

Si los cambios requieren un tiempo de inactividad planificado, debe crear la solicitud de cambio manualmente y enviarla para su aprobación. Una vez aprobada, puede iniciar el despliegue proporcionando el ID de la solicitud de cambio. La canalización comprueba su estado de aprobación y, a continuación, ejecuta el despliegue. Para obtener más información, consulte Aprobación manual de solicitudes de cambio.

Anexos previos al despliegue

Inmediatamente después de crear la solicitud de cambio, la canalización adjunta los siguientes artefactos al registro CR:

• Lista de materiales de implantación: enumera todos los componentes incluidos en la implantación
• Resumen Delta- postura de evidencia de todos los componentes que participan en el despliegue
• Archivo de configuración de comprobaciones de pruebas: sólo se adjunta si se ha configurado en la cadena de suministro el bloqueo basado en comprobaciones de pruebas
• Perfil SCC: sólo se adjunta si se ha configurado una configuración de seguridad y conformidad

Puerta de aprobación

Si la solicitud de cambio se creó como No aprobada, se coloca en estado no aprobado y se envía a revisión humana. No se produce ningún despliegue hasta que se concede la aprobación.

Puedes consultar el ID de la solicitud de cambio generada en los registros del canal, esperar a que se apruebe y, a continuación, reiniciar la implementación utilizando ese mismo ID de solicitud de cambio. La canalización comprueba el estado de aprobación y continúa el despliegue.

Pruebas de implantación y aceptación

Con el CR en estado Implementar, se ejecuta el pipeline:

• Despliegue de CD- promueve el código al entorno de destino
• Pruebas de aceptación: validan el resultado de la implantación

Estas dos son etapas de ejecución dirigidas por el usuario.

Cierre de la RC tras el despliegue

Cuando se superan las pruebas de despliegue y aceptación, la canalización adjunta los artefactos de cierre y cierra la solicitud de cambio:

• Resumen de cierre: un resumen de las evidencias de todas las entradas de inventario en el nivel de confirmación de destino.
• SBOM fusionada: la lista de materiales del software posterior a la implantación en todos los componentes del inventario.

El CR se cierra entonces con un close_category basado en DEPLOYMENT_READY en el momento del cierre:

Tipos de cambio

La gestión de solicitudes de cambio admite dos tipos de cambio: de emergencia o ordinario.

Si el cambio actual es un cambio de emergencia, añade la etiqueta « emergency » a la solicitud de incorporación de cambios de la promoción.

No hay flujo de emergencia en el lado de la tubería CI. Sin embargo, establecer la propiedad CI pipeline/trigger skip-inventory-update-on-failure a un valor vacío o 0 permite que el repositorio de inventario se actualice incluso si se detectan problemas en la ejecución de CI pipeline. Con este inventario actualizado, se puede activar un cambio de emergencia.

Elegir una vía de recuperación

Ruta 1: Reversión completa utilizando la escucha de reversión dedicada

Si existe una última configuración buena conocida, es decir, un estado previamente desplegado que se confirma estable, el camino más rápido para la restauración del servicio es una reversión completa. Para ello se utiliza un receptor de reversión específico creado para esta situación y que no requiere una nueva compilación o promoción.

Para obtener instrucciones paso a paso y los parámetros que se deben configurar, consulte Reversión completa mediante el receptor de reversión dedicado.

Ruta 2: Fix-forward como cambio de emergencia

Si no existe un objetivo de reversión viable, o si la investigación ya ha producido un parche, la corrección puede desplegarse como un cambio de emergencia. Esta vía cortocircuita la lógica estándar de bloqueo de pruebas: la canalización permite que el cambio se aplique inmediatamente, y la solicitud de cambio está sujeta a revisión y aprobación retroactivas una vez resuelto el incidente.

Utilizar esta vía significa aceptar que el código desplegado en producción puede contener aún vulnerabilidades no resueltas o lagunas de pruebas abiertas. El restablecimiento del servicio se considera la mayor prioridad, y los puntos de cumplimiento pendientes deben abordarse una vez cerrado el incidente.

Estas dos vías no se excluyen mutuamente. En la práctica, los equipos pueden iniciar primero un desmantelamiento completo para restablecer el servicio de inmediato y, a continuación, realizar una corrección una vez que el parche esté listo y validado. La secuenciación se deja al criterio del operador en función de la situación.

Procedimiento de fijación

Para implantar una corrección como cambio de emergencia durante una CIE, siga estos pasos:

1. Reconstruya el componente afectado. Ejecute la canalización CI para crear una nueva versión del artefacto que contenga la corrección. Si las comprobaciones de pruebas de CI fallan debido a las condiciones del incidente, establezca la propiedad de canalización o activación skip-inventory-update-on-failure en un valor vacío o 0 para permitir que el inventario se actualice a pesar de los fallos, de modo que se pueda proceder al cambio de emergencia.

2. Promover el arreglo a través de entornos. Cree pull requests de promoción empezando por el entorno más bajo y ascienda hacia la producción. Si el tiempo lo permite, verifique el arreglo en cada etapa antes de seguir avanzando. Si la situación es crítica, pase directamente a producción y reconcilie los entornos inferiores una vez restablecido el servicio.

3. Aplique la etiqueta de emergencia. En el pull request de promoción destinado a producción, añada la etiqueta emergency. Esto indica a la cadena de suministro que debe omitirse el bloqueo de pruebas estándar y que el cambio debe tratarse como un despliegue de emergencia.

4. Despliegue en producción. Ejecute el proceso de CD. La tubería detecta la etiqueta de emergencia, se salta la espera de aprobación y procede inmediatamente a las pruebas de despliegue y aceptación. La solicitud de cambio se crea y se cierra con close_category = successful with issues, lo que refleja que el cambio se desplegó en condiciones de emergencia.

5. Conciliar los entornos inferiores. Una vez resuelta la incidencia de producción, despliegue el mismo artefacto de corrección de emergencia en los entornos inferiores (ensayo, preproducción, etc.) para que todos los entornos se encuentren en un estado coherente con el de producción. Si se verificaron entornos inferiores antes de pasar a producción, confirme que existe la misma versión de artefacto en todos los niveles.

Obligaciones post-CIE

Un despliegue de emergencia conlleva obligaciones de cumplimiento que deben abordarse una vez cerrado el incidente:

• La solicitud de cambio debe ser revisada retroactivamente y aprobada por los responsables correspondientes.
• Cualquier laguna de pruebas aceptada durante la emergencia -vulnerabilidades no resueltas, escaneos incompletos o comprobaciones fallidas- debe subsanarse y la canalización debe volver a ejecutarse en condiciones estándar.
• Debe realizarse y documentarse un análisis de la causa raíz (ACR).

El registro de la solicitud de cambio, incluidos el Resumen Delta, el Resumen de Cierre y el SBOM Fusionado adjuntos por la canalización, sirve como pista de auditoría principal para la revisión posterior a la CIE.

Invocar el flujo de emergencia

El flujo de emergencia es iniciado por el usuario:

1. El usuario ejecuta el pipeline con la etiqueta emergency aplicada al pull request de promoción.
2. La tubería detecta la designación de emergencia y se procede inmediatamente al despliegue y a las pruebas de aceptación sin esperar a la aprobación estándar.
3. El CR se cierra con las notas de cierre como successful with issues.

Si el cambio actual es un cambio de emergencia, añade la etiqueta « emergency » a la solicitud de incorporación de cambios de la promoción antes de ejecutar el proceso de integración.

Despliegue posterior a la emergencia

Una vez que el flujo de emergencia completa el despliegue y las pruebas, vuelve a unirse al flujo estándar en la fase posterior al despliegue:

• El resumen de cierre y el SBOM fusionado se adjuntan a la RC.
• El CR se cierra siguiendo la misma lógica close_category basada en DEPLOYMENT_READY que el flujo estándar.

Si el tipo de CR es emergency, la solicitud de cambio debe revisarse y aprobarse retroactivamente tras la implantación.

Condición activadora

El flujo de retroceso en línea se introduce cuando no se superan las pruebas de despliegue o aceptación. A continuación, el proceso evalúa si la función de retroceso en línea está activada:

• Inline-Rollback no habilitado: El CR se deja abierto con close_category = unsuccessful y la tubería sale. No se intenta la recuperación automática.
• Rollback activado: El script de rollback se ejecuta para revertir el entorno de destino, y los artefactos de rollback se recopilan y se adjuntan al CR.

Ejecución Rollback en línea

Cuando el retroceso en línea está activado, la tubería:

1. Ejecuta el script inline-rollback si el despliegue o la prueba de aceptación ha fallado en el pipeline CD.
2. Recoge los siguientes artefactos:
   • Rollback Logs- salida de la ejecución del script rollback
   • Resumen de cierre- refleja el resultado de la reversión
   • SBOM fusionada: lista de materiales de software posterior al rollback
3. Adjunta los tres artefactos al registro CR abierto.

Cierre de CR después del rollback

Tras el retroceso en línea y la fijación del artefacto, el CR se deja abierto con close_category = unsuccessful. Esto indica a la gestión de cambios que la implantación se ha intentado, ha fallado y se ha revertido automáticamente.

Un CR con close_category = unsuccessful es el resultado esperado y correcto cuando se invierte un despliegue, no una indicación de un fallo del proceso. Los equipos de operaciones deben utilizar los registros de reversión adjuntos para investigar la causa raíz.

Ejecutar el pipeline con una solicitud de cambio preaprobada

Puede utilizar una solicitud de cambio (CR) preaprobada para la implantación. Hay dos escenarios posibles:

Cuando el canal de CD reconoce que el CR ha sido creado por una ejecución anterior del canal de CD, realiza un seguimiento rápido de la implantación:

• Reutilización del delta precalculado y el resumen de pruebas de las pruebas CR.
• Omisión de los pasos de revisión por pares y verificación de firmas.
• Implementación del delta precalculado.

Cuando el canal de CD no puede determinar si el CR fue creado por una ejecución anterior del canal de CD, o el CR proporcionado no coincide con el objetivo de despliegue de la ejecución actual:

• No reutiliza ningún delta precalculado ni resúmenes de pruebas.
• No omite la revisión por pares ni la verificación de firmas de artefactos.
• Vuelve a calcular el delta y el resumen desde cero.
• No crea un nuevo CR, puesto que ya se había suministrado uno.

Reejecutar el pipeline contra un despliegue fallido

Si no desea utilizar la gestión automatizada de cambios, puede presentar en su lugar una solicitud de cambio creada y aprobada previamente. Vuelva a ejecutar los despliegues fallidos en los escenarios siguientes:

• La última solicitud de cambio generada automáticamente no está lista para su implementación y no se ha aprobado automáticamente. Ha recibido la aprobación y debe reiniciar la implantación utilizando la misma solicitud de cambio.
• El despliegue requiere tiempo de inactividad. Tú creaste la solicitud de cambio, se aprobó y seguiste la política de gestión de cambios de tu organización.
• No se ha cambiado ningún código o configuración. Ha creado la solicitud de cambio, ha explicado qué ha cambiado, ha recibido la aprobación y ha iniciado una implantación utilizando la solicitud de cambio aprobada.

La solicitud de cambio (CR) permanece abierta una vez finalizado el proceso de CD.

Puedes iniciar el proceso de implementación continua de referencia de DevSecOps utilizando una solicitud de cambio previamente aprobada e introduciendo el ID de dicha solicitud en la propiedad « change-request-id ».

Si se ha establecido la propiedad «change-request-id», el proceso omite la recopilación de datos de la solicitud de cambio y pasa directamente a comprobar el estado de aprobación. Si el campo «change-request-id» está configurado de forma predeterminada en « notAvailable », el proceso de automatización crea automáticamente una solicitud de cambio.