Tu pipeline de CI es inestable y el equipo ha empezado a reintentar las builds en rojo sin leerlas. ¿Cómo lo arreglas?

Trata la inestabilidad como un incidente de producción, porque un pipeline en el que nadie confía no aporta ninguna seguridad. Mídela primero: sigue la tasa de aprobación y pon en cuarentena los tests que fallan de forma intermitente para que main vuelva a verde. Luego arregla los tests en cuarentena por causa, normalmente estado compartido, suposiciones de tiempos o una condición de carrera real. Impón una política de que la cuarentena es temporal, con responsable y fecha límite, para que no se convierta en un cementerio.

La parte peligrosa no es el tiempo perdido, es que la gente ha aprendido que rojo no significa roto, así que el día que caiga una regresión de verdad también la reintentarán hasta que pase. Empiezo midiendo, porque las opiniones sobre qué tests son inestables suelen ser erróneas. Vuelve a ejecutar la suite repetidamente sobre un commit sin cambios, o sigue las tasas de aprobación por test durante unos cientos de ejecuciones, y obtienes una lista ordenada. Luego pongo en cuarentena a los peores fuera de la ruta bloqueante para que main esté en verde y el rojo vuelva a significar algo, pero en cuarentena con responsable y fecha de caducidad, o si no se convierte en un cementerio que nadie mira. Al arreglarlos, las causas se agrupan: tests que comparten estado a través de una base de datos o un singleton, sleeps haciendo de esperas de verdad, y dependencia del orden. Y algunos son bugs reales. Una vez perseguí un test que fallaba una vez de cada cincuenta y resultó ser una carrera genuina en un pool de conexiones, que habría sido un problema intermitente de producción que nadie podía reproducir.