DevOps & QA Case Study

Troubleshooting en Producción: Caché de Vercel y Desincronización de Ramas

Análisis de un falso positivo en un despliegue donde los cambios locales no se reflejaban en el dominio principal debido a la persistencia de caché y conflictos en el control de versiones.

1. El Incidente (Síntomas)

Durante el despliegue de una refactorización en un formulario de contacto de Next.js (App Router), se reportó que el sistema seguía enviando las peticiones HTTP a un webhook obsoleto de n8n, a pesar de que el código fuente local ya había sido actualizado para apuntar a un nuevo endpoint interno (`/api/contact`).

La consola de Vercel indicaba que el build había sido exitoso y el estado de Git local mostraba el árbol de trabajo limpio, generando una discrepancia silenciosa entre el entorno de desarrollo y producción.

2. Auditoría y Diagnóstico QA

Inspección de Red (DevTools): Se interceptó la carga útil del formulario deshabilitando la caché del navegador local. Se comprobó que el Request URL efectivamente seguía apuntando al entorno de n8n, confirmando que Vercel estaba sirviendo un artefacto de código antiguo.
Análisis de Capas de Caché: Se intentó una purga del Full Route Cache y el Data Cache desde la infraestructura CDN de Vercel para descartar la retención agresiva de Next.js. El problema persistió.
Revisión de Control de Versiones: Al auditar el flujo CI/CD, se descubrió la causa raíz: el repositorio local estaba realizando pushes a la rama master, mientras que Vercel estaba configurado para escuchar y compilar exclusivamente los cambios en la rama main.

3. La Solución (Resolución)

Para estandarizar el proyecto con las convenciones actuales de la industria y restablecer el flujo de integración continua, se ejecutaron las siguientes acciones correctivas:

// 1. Migración de la rama local

$ git branch -M main

// 2. Sincronización con el origen remoto

$ git push -u origin main

Finalmente, desde el panel de Vercel, se restableció la asignación automática de dominios (Auto-assign custom domains) a la nueva rama main, logrando un despliegue exitoso donde el tráfico HTTP se enrutó correctamente hacia el nuevo endpoint de Nodemailer.

4. Lecciones Aprendidas

Un despliegue exitoso en consola no garantiza la entrega de valor al cliente. Este caso subraya la importancia de triangular las pruebas combinando herramientas de caja negra (interfaz), caja blanca (código local) y observabilidad de red (DevTools) para detectar brechas en la infraestructura CI/CD.