El deploy "exitoso" que no estaba en producción
Perdí más horas de las que me gustaría admitir persiguiendo un bug que ya estaba arreglado. El arreglo estaba en main, el pipeline estaba en verde, y sin embargo el comportamiento viejo seguía ahí. La conclusión fácil, “el fix no funciona”, era la equivocada. El fix funcionaba perfecto. Simplemente no estaba corriendo.
Desde entonces trato “el deploy salió verde” y “mi código está sirviendo” como dos afirmaciones separadas, y verifico la segunda explícitamente. Estas son las trampas en las que caigo, para que no caigas vos.
1. Un redeploy reusa el commit viejo
Cuando volvés a disparar un deploy existente para “aplicar la nueva config”, muchas plataformas reconstruyen el mismo commit fuente que la primera vez. Tu cambio nuevo no está ahí. Si querés el código actual, dispará un build fresco desde el head de la rama objetivo, no un redeploy del artefacto anterior.
2. El merge a main no siempre llega a producción
Si el auto-deploy está apagado, o la rama de producción no es la que pensás, tu merge se queda esperando. Revisá la config de auto-deploy y el mapeo de ramas antes de asumir que mergear propaga. Deployá explícitamente cuando el auto-deploy no está.
3. Nunca promuevas un build de preview o staging a producción
Un build hecho con la config de staging lleva las variables de entorno equivocadas. Promoverlo a prod arrastra esa config equivocada con él. Siempre construí fresco con las variables del entorno objetivo. Frontend y backend suelen deployarse por separado: verificá cada uno por su cuenta, no infieras el estado de uno mirando el otro.
4. Compará el commit desplegado contra el head que esperás
La verificación más directa: ¿qué SHA de commit se usó para construir el deploy vivo? Comparalo con el head de la rama que querías soltar. Si no coinciden, ahí está tu respuesta, sin teorías.
5. Confirmá que las rutas nuevas responden, y esquivá el caché
Que el proceso esté “ready” no prueba que el código nuevo sirve. Pegale a una ruta o feature específica de esta versión. Y hacelo con un cache-buster o mirando el header de cache-status, porque el caché de borde te puede mostrar contenido viejo con toda tranquilidad mientras el deploy nuevo ya está arriba.
La regla de fondo
Preferí el estado autoritativo del servidor por sobre la salida del cliente. Los logs de la consola del browser, la impresión optimista del pipeline: son señales ruidosas. El SHA del commit del deploy, la respuesta de una ruta específica pegándole con cache-busting: eso es autoritativo. Cuando una salida es ambigua, dejo de interpretarla y cambio a un chequeo determinístico.
Y una última: evitá los loops de polling. Un chequeo, un reporte de estado, un próximo paso claro. Estar pegándole cada cinco segundos a un build en progreso no lo hace terminar más rápido; solo te hace sentir productivo mientras esperás.
El día que separé “verde” de “sirviendo” en mi cabeza, mis sesiones de debugging se acortaron a la mitad. La mitad de los bugs de “no anda” son en realidad bugs de “no está desplegado”.