Post-deploy: rollbacks y observabilidad

Desplegar no es cruzar la meta, sino el instante en que el riesgo deja de ser hipotético y se vuelve real: el código que hasta entonces solo se había ejecutado en entornos controlados empieza a servir tráfico de verdad. La madurez en producción no consiste en desplegar sin miedo, sino en montar el bucle que hace el miedo innecesario, y ese bucle tiene cuatro movimientos. Verificar que el despliegue está sano antes de confiarle el tráfico, con healthchecks y smoke tests. Poder deshacer en segundos si algo va mal, con un rollback que reapunta a un despliegue inmutable anterior sin reconstruir nada. Observar qué ocurre de verdad, con telemetría de errores y de rendimiento real de usuario. Y cerrar el bucle, devolviendo esas señales de producción al pipeline para que la próxima vez fallen antes. Un despliegue sin estos cuatro pasos es un acto de fe; con ellos, es una operación reversible y medida.

Verificar antes de confiar

Un despliegue que termina sin error no es un despliegue sano: solo significa que el proceso de subida no falló, no que la app responda bien. Entre ambas cosas hay un abismo que se cruza con healthchecks: un endpoint de salud —/health o /healthz— que la app expone y que responde con éxito solo cuando de verdad puede atender tráfico. Conviene distinguir dos preguntas que suelen mezclarse. La liveness pregunta si el proceso está vivo y hay que reiniciarlo si no; la readiness pregunta si está listo para recibir peticiones ahora mismo, lo cual puede ser falso un rato tras arrancar aunque el proceso viva, mientras calienta cachés o abre conexiones. Dirigir tráfico a algo vivo pero no listo es servir errores con toda la confianza del mundo.

Aquí ayuda separar dos palabras que el habla cotidiana funde: desplegar y liberar. Desplegar es publicar el artefacto y dejarlo accesible en su URL propia; liberar es dirigirle el tráfico de usuarios reales moviendo el alias. La verificación vive justo en la rendija entre ambos: el despliegue ya existe y se puede sondear, pero todavía no es producción, así que puedes ejercitarlo sin arriesgar a nadie. Todo el post-despliegue seguro se apoya en mantener esa rendija abierta el tiempo suficiente para mirar antes de liberar.

Sobre esa base se monta el smoke test post-despliegue: un puñado de peticiones contra la URL recién desplegada —que, por ser inmutable, tiene dirección propia antes de ser producción— que comprueban las rutas críticas antes de reapuntar el alias. Si el smoke test falla, el alias no se mueve y los usuarios siguen viendo la versión anterior, intacta. La forma madura de este patrón es el despliegue gradual o canary: se dirige una fracción del tráfico al despliegue nuevo, se vigila su tasa de error y sus latencias unos minutos, y solo si se mantiene sano se promueve al cien por cien.

El despliegue gradual no es solo prudencia: acota el radio de impacto. Si el despliegue nuevo resulta defectuoso, solo la fracción de tráfico que le dirigiste sufre el fallo, no toda tu base de usuarios, y esa fracción es una palanca que ajustas según lo arriesgado que sea el cambio. Cada etapa del canary es una apuesta pequeña y reversible en lugar de una grande e irreversible.

Un detalle que separa un healthcheck útil de uno decorativo es su profundidad. Un check superficial que solo responde que el proceso atiende peticiones puede dar verde mientras la base de datos está caída; un check profundo comprueba de verdad las dependencias críticas —la conexión a datos, un servicio del que dependes— antes de declararse sano. El equilibrio es fino: demasiado profundo y una dependencia lenta tumba una instancia por lo demás sana; demasiado superficial y mientes sobre tu propia salud.

# smoke test que bloquea la promocion si algo falla
DEPLOY_URL="$(pnpm run deploy --json | jq -r .url)"
curl -fsS "$DEPLOY_URL/healthz" || exit 1
curl -fsS "$DEPLOY_URL/" > /dev/null || exit 1
echo "sano: promoviendo el alias a produccion"

Rollback instantáneo: reapuntar, no reconstruir

Aquí es donde el modelo de despliegues inmutables paga su mayor dividendo. Si cada build es un despliegue congelado con su propia URL y producción es solo un alias que apunta a uno de ellos, revertir no es reconstruir la versión anterior ni redesplegarla: es reapuntar el alias al despliegue inmutable previo, que sigue existiendo intacto porque nada lo borró. La operación dura lo que tarda en propagarse un cambio de puntero —segundos— y es segura por construcción, porque el despliegue al que vuelves es exactamente el que ya estuvo sirviendo tráfico sin problemas, bit por bit, no una reconstrucción que podría diferir.

Esto reordena la respuesta a incidentes. La tentación bajo presión es diagnosticar y arreglar hacia adelante, pero el forward-fix es lento e incierto justo cuando no puedes permitirte ninguna de las dos cosas. La disciplina correcta es revertir primero y diagnosticar después: el rollback devuelve el sistema a un estado bueno conocido en segundos, y solo entonces, sin usuarios afectados y sin el reloj corriendo, investigas la causa. El tiempo medio de recuperación deja de depender de lo rápido que encuentres el bug y pasa a depender solo de lo rápido que muevas el puntero.

Conviene no confundir este rollback con un git revert. Revertir el commit en el repositorio es una corrección hacia adelante disfrazada: genera un cambio nuevo que hay que construir y desplegar como cualquier otro, con su propio riesgo y su propia espera. El rollback del que hablamos no toca el repositorio en el momento del incidente; solo reapunta el alias a un artefacto que ya existe y ya funcionaba. El git revert viene después, con calma, para que el historial refleje la decisión.

Y hay una consecuencia cultural en que revertir sea tan barato: habilita desplegar seguido. Cuando deshacer un despliegue cuesta segundos y ningún riesgo, el coste esperado de un despliegue fallido se desploma, y con él la aversión a desplegar. Los equipos que publican muchas veces al día no son más valientes, sino que han hecho el error tan reversible que desplegar deja de dar miedo. La frecuencia de despliegue y la facilidad de rollback son, en el fondo, la misma propiedad vista desde dos lados.

Esto descansa en una condición silenciosa: que los despliegues antiguos sigan existiendo. Un rollback solo alcanza tan atrás como llegue la retención de artefactos inmutables que guarda tu plataforma; si se podan demasiado pronto, el puntero no tiene a dónde volver. Por eso conservar un historial razonable de despliegues no es acumular basura, sino mantener disponible el conjunto de estados buenos conocidos a los que podrías necesitar regresar en segundos.

flowchart TD
N[despliegue N nuevo] --> HC[healthcheck y smoke]
HC -->|verde| AL[alias de produccion apunta a N]
HC -->|rojo| STOP[el alias no se mueve]
AL --> ERR[telemetria detecta un pico de errores]
ERR --> RB[reapunta el alias a N-1]
RB --> OK[N-1 intacto vuelve a servir en segundos]
style AL fill:#89b4fa,color:#11111b
style RB fill:#f38ba8,color:#11111b
style OK fill:#a6e3a1,color:#11111b

Observabilidad: errores y rendimiento

Un despliegue reversible y verificado sigue siendo ciego si no ves qué le pasa en producción. La observabilidad de frontend descansa en dos pilares que responden preguntas distintas. El primero es la telemetría de errores: capturar las excepciones que ocurren en el navegador y en el servidor y agregarlas por versión. El detalle que la hace útil de verdad es subir los source maps en el pipeline; sin ellos, un error llega como una traza sobre código minificado ilegible; con ellos, la plataforma reescribe la traza a tu código fuente original, con archivo y línea reales. Etiquetar cada despliegue con una versión —un release— es lo que permite decir “los errores empezaron con este despliegue” en lugar de mirar una gráfica plana sin fronteras.

El segundo pilar es el rendimiento real de usuario, o RUM, y no hay que confundirlo con las mediciones de laboratorio. Un Lighthouse en CI mide una carga sintética en una máquina controlada; el RUM mide las Core Web Vitals —LCP, INP, CLS— tal como las viven usuarios reales, con sus redes lentas y sus dispositivos modestos. Solo el campo te dice la verdad sobre la experiencia; el laboratorio te da una señal temprana y repetible, pero no sustituye al campo. En el servidor, el equivalente es el tracing distribuido con OpenTelemetry y los logs estructurados, que convierten un “va lento” en una traza donde se ve exactamente qué tramo consumió el tiempo.

La distinción entre laboratorio y campo no es académica: gobierna dónde pones cada control. El laboratorio, barato y determinista, va en el pipeline como guarda temprana que rechaza una regresión antes de que llegue a nadie; el campo, que solo existe tras desplegar, va en producción como el juez final capaz de disparar una alerta o un rollback. Ninguno sustituye al otro, y confundir sus papeles deja un agujero por el que se cuelan justo los problemas que más importan.

En el lado del servidor esa observabilidad se apoya en tres señales que se complementan: las métricas agregan el comportamiento en números baratos de almacenar y graficar, las trazas siguen una petición concreta a través de cada servicio que toca y revelan dónde se fue el tiempo, y los logs estructurados guardan el detalle de cada evento como datos consultables en lugar de texto suelto. Emitirlas con un estándar común es lo que te deja cambiar de proveedor sin reinstrumentar la app.

Con las señales en su sitio, el último cuidado es alertar sobre síntomas, no sobre causas: una alerta debe dispararse cuando el usuario sufre —la tasa de error sube, la latencia se degrada, un Web Vital se sale de rango— y no por cada fluctuación interna sin efecto visible. Una alerta que no corresponde a un dolor real erosiona la confianza en todas las demás, y una guardia sepultada bajo ruido termina ignorando justo la que importaba.

# subir source maps al publicar, para trazas legibles en produccion
- run: pnpm build
- run: pnpm dlx @sentry/cli sourcemaps upload --release "$GITHUB_SHA" ./dist

// reportar Web Vitals de campo al endpoint de telemetria
import { onLCP, onINP, onCLS } from 'web-vitals';
const send = (m) => navigator.sendBeacon('/rum', JSON.stringify(m));
onLCP(send); onINP(send); onCLS(send);

Cerrar el bucle

Los tres pasos anteriores todavía dejan a producción como un destino: el sitio donde el código termina su viaje. El paso que falta convierte producción en una fuente, la que alimenta de vuelta al pipeline. Cerrar el bucle es tomar las señales que produce la observabilidad y volverlas guardas que actúan antes, más cerca del origen: un presupuesto de tamaño de bundle que rompe el CI cuando una dependencia lo infla; una regresión de INP medida en campo que bloquea la promoción del siguiente despliegue; un pico de tasa de error que, cruzado el umbral, dispara un rollback automático sin esperar a que un humano despierte.

Esto es lo que une la entrega y la operación en un solo sistema con realimentación. Los SLO y su presupuesto de error dan el lenguaje: defines qué nivel de fallo es tolerable, mides cuánto de ese presupuesto consumes, y ese consumo gobierna el ritmo —si te lo estás gastando, frenas los despliegues arriesgados; si te sobra, aceleras—. El bucle completo es dev, deploy, observe y de vuelta a dev, y su virtud es que cada vuelta hace la siguiente más segura, porque cada incidente que observas en producción se traduce en una guarda que lo atrapará antes la próxima vez. Producción deja de ser el final de la tubería y pasa a ser el sensor que la calibra.

Fíjate en que este bucle es lo que da sentido operativo a los SLO: un objetivo de nivel de servicio no es un número para un informe, sino el umbral que gobierna el ritmo. Cuando la tasa a la que consumes tu presupuesto de error —tu burn rate— se dispara, el bucle reacciona frenando los despliegues arriesgados y volcando el esfuerzo en estabilizar; cuando el presupuesto sobra, el mismo bucle autoriza a arriesgar más y a moverse rápido. El presupuesto de error convierte la fiabilidad de una aspiración vaga en un recurso medible que se gasta y se repone.