App Next.js llevada a producción con CI/CD y rollback

La app funcionaba. Ese era parte del problema.

Cuando algo “funciona” en desarrollo, es tentador empujarlo a producción con la misma lógica: un servidor, variables copiadas a mano, deploy por SSH, build local y fe. Sirve una vez. Después aparece la primera urgencia: un hotfix sin registro, una variable distinta entre ambientes, una dependencia que cambia, un build que falla justo cuando hay demo.

El cliente tenía una app Next.js con usuarios reales acercándose. No era enterprise. No necesitaba Kubernetes. Necesitaba producción sin teatro.

Partimos por separar preguntas.

Qué debe vivir en la plataforma. Qué debe vivir en el repositorio. Qué debe ser secreto. Qué debe quedar documentado. Qué se puede romper sin afectar usuarios. Qué necesita rollback. Qué métrica avisa antes del reclamo.

La arquitectura final fue deliberadamente simple: repositorio como fuente de verdad, pipeline de CI, deploy automático desde rama principal, previews por pull request, variables separadas por ambiente, chequeos de build, healthcheck, logs accesibles y rollback probado. Nada exótico. Nada que requiera un equipo DevOps permanente para entenderlo.

El trabajo pesado fue ordenar el borde.

Revisamos variables de entorno y eliminamos duplicados. Separamos claves públicas de secretos. Detectamos dependencias que asumían localhost. Ajustamos configuración para que staging y producción se comportaran distinto sin bifurcar código. Validamos rutas críticas: login, dashboard, formularios, webhooks y tareas que dependían de APIs externas.

Después armamos el pipeline.

Cada cambio debía pasar por instalación limpia, lint, typecheck y build. Si fallaba ahí, no llegaba a producción. Si pasaba, el despliegue quedaba trazado: commit, autor, fecha, resultado. Para previews, cada PR generaba una URL revisable. Eso bajó ruido: ya no había que decir “en mi máquina se ve bien”; se podía abrir el link y mirar lo mismo.

También dejamos rollback explícito.

No basta con que la plataforma tenga un botón. Hay que saber cuándo usarlo y qué implica. Probamos volver a la versión anterior. Confirmamos que variables, migraciones y caché no dejaran el sistema en estado raro. Documentamos el criterio: rollback si hay error crítico de autenticación, checkout, pérdida de datos o indisponibilidad persistente. Fix forward si el impacto es menor y está acotado.

La parte de costos importó.

Una app pequeña no necesita sobreingeniería. Elegimos servicios administrados donde reducen carga operativa y evitamos piezas que cobran por estar ociosas. Dejamos alertas simples para detectar crecimiento real antes de sobredimensionar. El punto no era gastar lo mínimo hoy; era no construir una cuenta mensual incomprensible para mañana.

Al final, producción dejó de ser una persona con acceso SSH.

Quedó un flujo: PR, preview, revisión, merge, build, deploy, monitoreo, rollback. El fundador pudo mostrar avances sin pedir “¿puedes subir esto?”. El equipo técnico ganó una línea clara entre cambios normales e incidentes. Y cuando algo falló en una integración externa, había logs y trazabilidad para resolver, no intuición.

La lección: lanzar una app Next.js no exige ceremonia. Exige límites sanos.

Un stack pequeño puede operar bien si tiene tres cosas: builds repetibles, secretos bajo control y camino de reversa. Lo demás se agrega cuando el negocio lo pide, no antes.