Saltar al contenido principal

Checklist de Deployment

Utiliza esta lista antes, durante y después de cada despliegue. Marca los elementos según corresponda.

1. Preparación (Pre-Deployment)

  • Revisar checklist de producción y confirmar que no quedan items críticos
  • Actualizar .env del backend con claves live (Stripe, JWT, SMTP, GHL, n8n)
  • Actualizar .env del frontend (VITE_*, PUBLIC_*)
  • Configurar DNS y certificados TLS para FRONTEND_HOST, BACKEND_HOST y DOCS_HOST
  • Validar migraciones pendientes (alembic heads)
  • Hacer backup de base de datos y Redis (o snapshot gestionado)
  • Verificar que Stripe y GHL están configurados según las guías de setup
  • Actualizar imágenes Docker si aplica (docker compose build --no-cache)

2. Ejecución (Deployment)

  • Aplicar migraciones: docker compose run --rm backend alembic upgrade head
  • Desplegar servicios: docker compose up -d (o pipeline equivalente)
  • Confirmar healthchecks (/health, logs de backend/frontend/docs)
  • Verificar reverse proxy / TLS (certificados emitidos y redirecciones correctas)

3. Verificación Post-Deployment

  • Ejecutar smoke tests: login, creación de proyecto, flujo de pago con tarjeta de prueba
  • Confirmar recepción de emails transaccionales
  • Verificar webhooks en Stripe y GoHighLevel (dashboard sin errores)
  • Revisar métricas/logs (Prometheus/Grafana si aplican)
  • Completar registro en ghl_sync_log sin fallos
  • Verificar que la documentación está accesible en doc.haorp.es
  • Actualizar documentación interna si hubo cambios relevantes

4. Rollback / Contingencia

  • Documentar el comando para revertir migraciones si fuera necesario (alembic downgrade -1)
  • Mantener backups accesibles
  • Tener a mano scripts docker compose down y versiones previas de imágenes

5. Release específico de Disputas

  • Confirmar contrato API final publicado (/backend/api): creación, detalle, mediación y resolución de disputas
  • Validar máquina de estados documentada (/backend/projects) y side effects de pagos/proyecto
  • Ejecutar smoke funcional de disputas:
    • Empresa crea disputa -> admin resuelve -> empresa ve resolved
    • Experto crea disputa -> admin media -> experto ve in_review
    • Usuario no relacionado recibe 403 en ver/crear disputa
  • Verificar trazabilidad de auditoría ([DISPUTE_EVENT] en project.admin_notes)
  • Confirmar notificaciones para mediación y resolución a ambas partes

6. Criterios de observabilidad (Post-Deploy)

  • Dashboard/queries muestran volumen de disputas abiertas vs resueltas en las últimas 24h
  • Monitorear ratio de errores 4xx/5xx en endpoints de disputas (/api/projects/*/dispute, /api/admin/disputes/*)
  • Alerta operativa definida para:
    • Disputas open con antigüedad mayor a SLA interno
    • Picos anómalos de creación de disputas
    • Fallos en resolución/mediación por permisos o validaciones

7. Comunicación

  • Avisar al equipo de soporte/marketing del despliegue
  • Programar monitorización extra las primeras 24 h (alertas en Stripe/GHL/logs)

8. Checklist de Staging

Checklist específico para despliegues en el entorno de staging (dev.floutic.com).

Pre-Deployment (Staging)

  • Verificar que producción NO se ve afectada: los servicios de prod siguen healthy
  • Confirmar que floutic_dev existe y las migraciones están aplicadas
  • Variables de entorno actualizadas en Coolify UI (verificar STRIPE_SECRET_KEY empieza con sk_test_)
  • JWT_SECRET de staging es DISTINTO al de producción
  • DATABASE_URL apunta al contenedor postgres propio (postgres:5432/floutic_dev)
  • REDIS_URL apunta al contenedor redis propio (redis:6379/0)

Deployment (Staging)

Staging se despliega automáticamente al hacer push a la branch dev:

# El deploy es automático via webhook
git push origin dev

Para deploy manual desde Coolify UI: navegar a la app staging y pulsar "Deploy".

  • Coolify muestra el deploy como exitoso
  • Health check responde: curl -sf -u floutic:floutic123 https://dev.floutic.com/api/v1/health
  • Frontend accesible: curl -sf -u floutic:floutic123 https://dev.floutic.com

Post-Deployment (Staging)

  • Verificar que producción sigue respondiendo en floutic.com
  • Confirmar que Stripe está en modo test (verificar webhook en dashboard)
  • Ejecutar smoke tests en dev.floutic.com (con Basic Auth)
  • Revisar logs desde Coolify UI o docker logs en el servidor

Rollback (Staging)

# Desde Coolify UI: pulsar "Redeploy" en el commit anterior
# O via git:
git push origin <previous-commit-sha>:dev --force
tip

Staging tiene sus propios contenedores de PostgreSQL y Redis, completamente aislados de producción. Se puede detener, reiniciar o destruir sin afectar producción.

Más Información