Actualizar Producción (Deploy de Cambios)

Esta guía es para actualizar una aplicación que ya está en producción. Si es tu primer deploy, consulta la Guía de Despliegue a Producción.

🎯 Cuándo Hacer Deploy

Haz deploy a producción cuando:

• ✅ El feature está completo y probado localmente
• ✅ El código está mergeado a main (o la rama de producción)
• ✅ Tests E2E pasando (si aplica)
• ✅ Code review aprobado
• ✅ No hay errores de compilación

Evita hacer deploy:

• ❌ Con código a medio implementar
• ❌ Con tests fallando
• ❌ Viernes en la tarde (por si surge un problema)
• ❌ Sin backup reciente de la DB (si hay migraciones)

---

⚡ Proceso Rápido (TL;DR)

Si ya conoces el proceso, aquí está la versión corta:

# 1. Actualizar main
git checkout main && git pull origin main

# 2. Deploy
cd app
wasp deploy fly deploy

# 3. Verificar
flyctl logs -a talentbricksai

---

📋 Checklist Pre-Deploy

Antes de hacer deploy, verifica:

1. Estado del Código

# Asegúrate de estar en main actualizado
git checkout main
git pull origin main

# Verifica que no hay cambios pendientes
git status
# Debe mostrar: "nothing to commit, working tree clean"

# Ver los últimos commits que se van a desplegar
git log --oneline -10

2. Cambios en el Schema de Base de Datos

# Ver si hay cambios en schema.prisma desde el último deploy
git diff <ultimo-deploy-commit> HEAD -- app/schema.prisma

# Si hay cambios, verifica las migraciones
ls -la app/migrations/

⚠️ IMPORTANTE: Si hay cambios en schema.prisma:

• Las migraciones se ejecutarán automáticamente durante el deploy
• Asegúrate de tener un backup de la base de datos antes de continuar
• Considera hacer el deploy en horario de bajo tráfico

Cómo hacer backup de Neon:

# Instalar pg_dump si no lo tienes (macOS)
brew install postgresql

# Hacer backup
pg_dump "$(flyctl secrets list -a talentbricksai | grep DATABASE_URL | awk '{print $2}')" \
  > backup-$(date +%Y%m%d-%H%M).sql

3. Nuevas Variables de Entorno

# Revisa si hay cambios en los archivos de ejemplo
git diff <ultimo-deploy-commit> HEAD -- app/.env.server.example app/.env.client.example

Si hay nuevas variables, configúralas en Fly:

# Ver secrets actuales
flyctl secrets list -a talentbricksai

# Agregar nueva variable
flyctl secrets set NUEVA_VARIABLE="valor" -a talentbricksai

# Para el cliente (si aplica)
flyctl secrets set REACT_APP_NUEVA_VAR="valor" -a talentbricksai-client

4. Verificación Local

cd app

# Asegúrate que compila sin errores
wasp build

# Si hay tests, córrelos
npm test

---

🚀 Proceso de Deploy

Paso 1: Posicionarse en el Directorio Correcto

cd app

Paso 2: Ejecutar el Deploy

wasp deploy fly deploy

Este comando hace todo automáticamente:

1. ✅ Construye el servidor Node.js
2. ✅ Construye el cliente React
3. ✅ Ejecuta migraciones de base de datos (si hay cambios en schema.prisma)
4. ✅ Despliega el servidor a talentbricksai.fly.dev
5. ✅ Despliega el cliente a talentbricksai-client.fly.dev
6. ✅ Reinicia las aplicaciones

Tiempo estimado: 3-5 minutos

Paso 3: Monitorear el Deploy

Mientras el deploy está en progreso, verás algo como:

==> Building image
--> Building image done
==> Pushing image to fly
--> Pushing image done
==> Creating release
--> Release created
==> Monitoring deployment
 1 desired, 1 placed, 1 healthy, 0 unhealthy [health checks: 1 total, 1 passing]
--> v23 deployed successfully

Si ves “deployed successfully”, el deploy fue exitoso.

---

✅ Verificación Post-Deploy

Después del deploy, siempre verifica que todo funciona correctamente.

1. Verificar Status de las Apps

# Estado del servidor
flyctl status -a talentbricksai

# Estado del cliente
flyctl status -a talentbricksai-client

# Ambos deben mostrar:
# Status: running
# Health Checks: passing

2. Revisar Logs en Tiempo Real

# Ver logs del servidor (presiona Ctrl+C para salir)
flyctl logs -a talentbricksai -f

# En otra terminal, ver logs del cliente
flyctl logs -a talentbricksai-client -f

Qué buscar en los logs:

• ✅ No debe haber errores rojos
• ✅ Migraciones deben completarse si las había
• ✅ “Server listening on port…” indica que el servidor arrancó
• ❌ Si ves “Error”, “Failed”, “Exception” → investiga inmediatamente

3. Verificar la Aplicación en el Navegador

Abre en tu navegador:

• Cliente: https://talentbricksai-client.fly.dev (o tu dominio custom)
• API: https://talentbricksai.fly.dev/api/health (debe retornar status 200)

Checklist funcional:

• La página carga sin errores
• Login funciona
• El feature que desplegaste está visible y funcional
• No hay errores en la consola del navegador (F12 → Console)
• Las integraciones críticas funcionan (Stripe, email, etc.)

4. Verificar Migraciones de Base de Datos

Si hubo cambios en schema.prisma:

# Conectar a la DB de producción (solo lectura)
flyctl ssh console -a talentbricksai -C "npx prisma studio"

# O ejecuta una query directa
flyctl ssh console -a talentbricksai -C "npx prisma db execute --stdin" <<< "SELECT * FROM _prisma_migrations ORDER BY finished_at DESC LIMIT 5;"

Verifica que:

• La migración aparece en la tabla _prisma_migrations
• No hay migraciones con rolled_back_at != NULL
• Las nuevas columnas/tablas existen

---

🔄 Rollback (Revertir un Deploy)

Si el deploy causó problemas, puedes revertir al deploy anterior.

Opción 1: Rollback Automático de Fly.io

# Ver historial de releases
flyctl releases -a talentbricksai

# Ejemplo de output:
# VERSION STABLE  TYPE    STATUS          DESCRIPTION
# v24     true    deploy  successful      Deploy from local
# v23     false   deploy  successful      Deploy from local
# v22     false   deploy  successful      Deploy from local

# Hacer rollback a la versión anterior
flyctl releases rollback v23 -a talentbricksai

# También para el cliente si es necesario
flyctl releases rollback v15 -a talentbricksai-client

Opción 2: Rollback con Git

# 1. Revertir el commit problemático
git revert <commit-hash-problematico>
git push origin main

# 2. Redesplegar
cd app
wasp deploy fly deploy

Opción 3: Rollback de Migraciones de Base de Datos

⚠️ PELIGROSO: Solo en casos extremos.

# Conectar a la DB de producción
flyctl ssh console -a talentbricksai

# Dentro de la máquina:
cd /app
npx prisma migrate resolve --rolled-back <nombre-migracion>

Mejor alternativa: Restaurar desde backup si hay problemas serios con la DB.

---

🐛 Troubleshooting

Error: “No such app”

# Verifica que estás en el directorio correcto
pwd
# Debe mostrar: .../app

# Verifica que las apps existen
flyctl apps list

# Si no aparecen, revisa la configuración
cat fly-server.toml | grep app
cat fly-client.toml | grep app

Error: “Database migration failed”

# Ver qué migración falló
flyctl logs -a talentbricksai | grep -i migration

# Ver estado de migraciones
flyctl ssh console -a talentbricksai -C "npx prisma migrate status"

# Si necesitas marcar una migración como aplicada manualmente
flyctl ssh console -a talentbricksai -C "npx prisma migrate resolve --applied <nombre-migracion>"

Error: “Build failed”

# Limpiar build anterior
cd app
wasp clean

# Intentar build local primero
wasp build

# Si falla localmente, arreglar antes de redesplegar
# Si funciona localmente, reintentar deploy
wasp deploy fly deploy

Error: “Health checks failing”

# Ver logs detallados
flyctl logs -a talentbricksai

# Ver máquinas
flyctl machines list -a talentbricksai

# Si una máquina está en estado "stopped", reiniciar
flyctl apps restart talentbricksai

Cliente no puede conectar al servidor

Problema: El cliente apunta a localhost en lugar del servidor de producción.

# Verificar REACT_APP_API_URL en el cliente
flyctl ssh console -a talentbricksai-client -C "cat .env | grep API_URL"

# Debe ser:
# REACT_APP_API_URL=https://talentbricksai.fly.dev

# Si está mal, el problema es que wasp deploy fly no configuró correctamente
# Necesitas reconstruir el cliente con la variable correcta

Cambios no se reflejan en producción

# 1. Verificar que el deploy fue exitoso
flyctl releases -a talentbricksai

# 2. Hard refresh en el navegador
# Mac: Cmd + Shift + R
# Windows: Ctrl + Shift + R

# 3. Limpiar caché de Fly CDN (si aplica)
flyctl apps restart talentbricksai-client

# 4. Verificar versión del código desplegado
flyctl ssh console -a talentbricksai -C "cat package.json | grep version"

---

📊 Monitoreo Post-Deploy

Después de un deploy exitoso, monitorea la aplicación durante las siguientes 24 horas.

Métricas Clave

# CPU y memoria
flyctl metrics -a talentbricksai

# Requests por minuto
flyctl logs -a talentbricksai | grep "GET\|POST" | wc -l

# Errores en las últimas horas
flyctl logs -a talentbricksai | grep -i "error" | tail -50

Dashboard de Fly.io

Visita: https://fly.io/dashboard/talentbricksai

Monitorea:

• CPU usage (debe estar < 80%)
• Memory usage (debe estar < 80%)
• Request latency (debe ser < 500ms)
• Error rate (debe ser < 1%)

Dashboard de Neon (Base de Datos)

Visita: https://console.neon.tech

Monitorea:

• Active connections (debe ser estable)
• Query duration (debe ser < 100ms promedio)
• Storage usage (no debe crecer inesperadamente)

---

📝 Documentar el Deploy

Después de cada deploy importante, documenta:

1. En IMPLEMENTATION.md (cambios técnicos):

## [2026-02-26] Deploy v24: Landing Page B2B

**Schema changes:**

- Added `DemoRequest` model for /teams landing page

**Features deployed:**

- B2B corporate landing page at /teams
- Admin user management (create/edit/delete users)
- Subscription validation system

**Migrations:**

- 20260226_add_demo_request_model

2. En changelog.md (cambios visibles al usuario):

## [26 Feb 2026] - Lanzamiento de TalentBricks para Equipos

### Nuevo

- 🏢 Landing page corporativa en /teams para empresas
- 👥 Los administradores ahora pueden crear y editar usuarios desde el panel admin

### Mejorado

- ⚡ Validación de suscripciones más robusta

---

⏱️ Frecuencia de Deploys

Recomendaciones

• Features pequeños: Deploy inmediatamente después de merge a main
• Features grandes: Deploy después de testing exhaustivo
• Hotfixes críticos: Deploy inmediatamente (ej. bugs de seguridad)
• Migraciones de DB: Deploy en horario de bajo tráfico

Horarios Recomendados

Tipo de Deploy	Mejor Horario	Evitar
Features normales	Lunes-Jueves 10am-4pm	Viernes tarde, fines de semana
Hotfixes	Cualquier momento	-
Migraciones grandes	Martes-Miércoles 6am o 10pm (bajo tráfico)	Lunes, horas pico
Deploy mayor	Martes-Miércoles por la mañana	Viernes, lunes, fines de semana

---

🎯 Mejores Prácticas

1. Deploy Frecuente, Cambios Pequeños

✅ Mejor: 5 deploys pequeños a la semana ❌ Evitar: 1 deploy gigante al mes

Por qué: Cambios pequeños son más fáciles de debuggear y revertir.

2. Siempre Monitorea los Logs

# Deja esto corriendo durante los primeros 5 minutos post-deploy
flyctl logs -a talentbricksai -f

3. Comunica los Deploys al Equipo

[Slack #deploys]
🚀 Deploy v24 a producción
- Landing page /teams
- Admin user management
- Migraciones: added DemoRequest model
⏰ ETA: 5 min

4. Ten un Plan de Rollback

Antes de cada deploy, pregúntate:

• ¿Qué hago si esto falla?
• ¿Puedo hacer rollback sin perder datos?
• ¿Hay cambios irreversibles en la DB?

5. No Hagas Deploys Grandes los Viernes

Si algo sale mal, tendrás que arreglarlo en fin de semana. Deploys grandes = martes o miércoles.

---

🔗 Enlaces Relacionados

• Despliegue a Producción (Primer Deploy)
• Workflow Desarrollo vs Producción
• Setup Local
• Database Schema
• Fly.io Docs - Deployments
• Wasp Docs - Deployment

---

✅ Checklist Final

Antes de cerrar este documento, asegúrate de haber completado:

• Pre-deploy checklist completado
• Deploy ejecutado con éxito
• Logs revisados (sin errores)
• Aplicación verificada en el navegador
• Features nuevos probados en producción
• Migraciones verificadas (si aplica)
• Cambios documentados en IMPLEMENTATION.md y changelog.md
• Equipo notificado del deploy
• Monitoreo configurado para las próximas 24h

---

¿Problemas durante el deploy? Consulta la sección de Troubleshooting o contacta al equipo en Slack #tech-support.