Gestión de cambios y despliegue: evidencia del pipeline

La gestión de cambios descansa en una idea vieja: segregación de funciones. Quien escribe o despliega un cambio no debe ser quien lo aprueba, porque entonces nadie lo controla. En un pipeline, esa idea se vuelve campos concretos del registro: ticket, aprobador, resultado del análisis de seguridad.

Un cambio urgente es una excepción legítima, pero con condiciones: se documenta, se aprueba y se revisa después. La excepción sin revisión posterior es solo un atajo.

El primer requisito de la política para un cambio normal es el ticket: sin él no hay quién haya pedido el cambio ni dónde se aprobó. El registro del pipeline tiene una columna para el ticket; vacía, significa que el cambio llegó a producción sin pedido.

Abre politica_de_cambios y despliegues_a_produccion.

Para un cambio normal, la política exige que el análisis de seguridad del pipeline resulte Aprobado. Para uno urgente puede omitirse. Por eso un análisis Omitido no es siempre un hallazgo: depende del tipo de cambio. El auditor mira las dos columnas juntas.

La política dice que un cambio urgente se revisa dentro de 2 días desde el despliegue. Para cada despliegue urgente hay que leer la fecha del despliegue y la de la revisión posterior. Si la revisión llegó después del plazo, o no existe, el urgente incumple.

Cuenta los despliegues de tipo Urgente cuya revisión posterior está vacía o cae más de dos días después de la fecha del despliegue.

El sentido en que se toma la muestra cambia lo que se puede descubrir. Si se parte de los tickets aprobados, nunca aparece el despliegue que se hizo sin ticket. La población de una prueba de despliegues es lo que llegó a producción, y esa lista sale del pipeline, no de la herramienta de tickets.