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
.envdel backend con claves live (Stripe, JWT, SMTP, GHL, n8n) - Actualizar
.envdel frontend (VITE_*,PUBLIC_*) - Configurar DNS y certificados TLS para
FRONTEND_HOST,BACKEND_HOSTyDOCS_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_logsin 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 downy 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
403en ver/crear disputa
- Empresa crea disputa -> admin resuelve -> empresa ve
- Verificar trazabilidad de auditoría (
[DISPUTE_EVENT]enproject.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
opencon antigüedad mayor a SLA interno - Picos anómalos de creación de disputas
- Fallos en resolución/mediación por permisos o validaciones
- Disputas
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_devexiste y las migraciones están aplicadas - Variables de entorno actualizadas en Coolify UI (verificar
STRIPE_SECRET_KEYempieza consk_test_) -
JWT_SECRETde staging es DISTINTO al de producción -
DATABASE_URLapunta al contenedor postgres propio (postgres:5432/floutic_dev) -
REDIS_URLapunta 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 logsen 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.