Retirar el parche cuando llega el arreglo

Que el ticket de desarrollo esté cerrado no autoriza a retirar nada. Hacen falta tres cosas, y se comprueban en tres archivos distintos: que el arreglo esté desplegado en producción —no en una rama de trabajo—, que exista una prueba de regresión viva que falle si el fallo vuelve, y que alguien haya comprobado en preproducción cómo se comporta la aplicación con el parche apagado.

La tercera es la que más se salta y la que explica los sustos: mientras el parche está puesto, el arreglo nunca se pone a prueba de verdad, porque el borde detiene la petición antes de llegar. Apagar el parche en preproducción es la única forma de saber que el arreglo aguanta solo.

Y retirar tampoco es solo borrar la regla. Conviene dejar unas semanas la alerta de registro sobre esa ruta: si alguien vuelve a intentar lo mismo contra código ya corregido, quieres verlo.

Abre el laboratorio y cruza los tres archivos. Busca el parche cuyo arreglo aparece como desplegado en el inventario, tiene su versión fechada en las notas con el ticket correspondiente, y en las pruebas de regresión aparece con la prueba en la batería de cada despliegue y con la comprobación en preproducción hecha. Solo uno cumple las tres.

Ahora mira la columna de la fecha en la que se esperaba poder retirar cada parche y compárala con la fecha de la revisión que trae el encargo. Varios la pasaron hace tiempo, algunos por más de un año, y su arreglo ni siquiera ha empezado. Esa cuenta es el número que entiende la dirección.

Hay un parche con el arreglo desplegado desde octubre y la prueba de regresión escrita, pero marcada para omitirse porque hacía lenta la batería. Una prueba que no corre no demuestra nada, aunque exista el archivo. Y mientras no corra, nadie sabe si el arreglo sigue en pie después de los despliegues que vinieron detrás.