Deploy Checklist — Golden Path

Objetivo: Desplegar siempre igual, sin improvisación. Seguir estos pasos en orden. Aplica a: CreaRack Pro (Hetzner PROD via Dokploy)

Pre-Deploy

• Tests pasan: docker compose exec web python -m pytest tests/api/ -v
• No hay migraciones pendientes: docker compose exec web python manage.py showmigrations --plan | grep "\[ \]" (vacío = OK)
• Si hay migraciones nuevas: verificar que son backward-compatible (no borran columnas usadas)
• git status limpio (sin cambios sin commitear)
• git pull --rebase origin main ejecutado
• Revisar CHANGELOG.md — los cambios están documentados

Deploy

• Push a main: git push origin main
• Verificar que Dokploy recibe el webhook: dashboard Dokploy → Deployments
• Esperar a que el build termine (2-3 min típico)
• Si el build falla: revisar logs en Dokploy, NO forzar re-deploy sin entender el error

Post-Deploy (verificación)

• Health check: curl -s https://crearack.com/health → debe devolver 200
• Logs limpios: ssh root@crearack.com "docker logs crearack-pro-zcmvsl-web-1 --tail 20" → sin errores
• Login funciona: abrir https://crearack.com en browser, hacer login
• Migraciones aplicadas: ssh root@crearack.com "docker exec crearack-pro-zcmvsl-web-1 python manage.py showmigrations --plan | grep '\[ \]'" → vacío
• UptimeRobot: verificar que no hay alerta (uptimerobot.com)

Si algo falla (Rollback)

1. No entrar en pánico — los datos están seguros (DB no se toca en rollback)
2. En Dokploy: ir al deploy anterior → “Redeploy” (usa la imagen del commit anterior)
3. Si Dokploy no responde: ssh root@crearack.com "docker rollback crearack-pro-zcmvsl-web-1" (si Swarm) o docker service update --rollback
4. Verificar que la versión anterior funciona (health check + login)
5. Investigar el problema en local antes de re-intentar

Casos especiales

Deploy con migraciones

• Ejecutar migraciones ANTES de desplegar nuevo código si es backward-compatible
• Si la migración no es backward-compatible: deploy en 2 pasos (migración primero, código después en el siguiente deploy)

Deploy de cambios docs-only

• Push inmediato como cualquier otro commit, sin [skip ci] (política equipo desde 30-04-2026)
• Dokploy puede saltar el rebuild si el cambio no toca código ejecutable, pero CF Pages Deploy y Bibliotecario-Ingest sí corren — eso es lo que queremos
• Excepción única: emergencia explícita autorizada con motivo en el commit message (avisar al equipo, el deploy también se salta)

Deploy de emergencia (hotfix)

• Hacer branch edu/hotfix-XXX desde main
• Fix mínimo, test, merge a main
• Push inmediato — no esperar a acumular más cambios
• Post-mortem: documentar qué falló y por qué en WORKLOG.md

Véase también

• [[crearack-tech—guides—production-deployment]] — deploy en producción Hetzner
• [[crearack-tech—admin—dokploy-guide]] — guía de Dokploy
• [[crearack-tech—admin—dokploy-internals]] — internals de Dokploy
• [[crearack-tech—guides—docker-guide]] — guía de Docker Compose
• [[crearack-tech—guides—disaster-recovery]] — procedimiento de disaster recovery
• [[decision—20251201—dokploy-vs-kubernetes]] — ADR Dokploy vs Kubernetes