proyectosacc-mirror/docs/10-runbook-rollback.md

10 - Runbook: Rollback

Cómo regresar a la versión anterior de la aplicación cuando algo sale mal.

---

1. ¿Qué es un rollback?

Un rollback es el proceso de "deshacer" un despliegue. Si la nueva versión de la aplicación tiene errores, el rollback vuelve a poner la versión anterior para que los usuarios no se vean afectados.

💡 Analogía simple: es como cuando instalas una actualización en tu celular y algo deja de funcionar, así que regresas a la versión anterior del sistema.

---

2. ¿Cuándo hacer un rollback?

Haz rollback inmediatamente si ves alguna de estas situaciones:

• 🔴 El health check falla después del despliegue.
• 🔴 La aplicación se cae al poco tiempo de iniciar.
• 🟡 Los usuarios reportan errores graves que no existían antes.
• 🟡 El pipeline detectó un fallo en el paso de deploy.
• 🟠 El servicio de systemd no puede arrancar.

⚠️ Regla de oro: si dudas, haz rollback. Es mejor tener la versión anterior estable mientras investigas el problema.

---

3. Paso a paso: cómo hacer rollback

El rollback ahora tiene dos partes: el frontend en S3 y la API en la EC2.

---

PARTE A: Rollback del frontend en S3

Si el problema es visual (interfaz rota, pantalla en blanco, etc.), restaura el frontend anterior.

Paso A1: Lista las versiones anteriores del archivo index.html

aws s3api list-object-versions \
  --bucket ccsoft-proyectosacc-frontend \
  --prefix index.html \
  --query 'Versions[?IsLatest==`false`].[VersionId,LastModified]' \
  --output table

Paso A2: Restaura la versión anterior

Copia el VersionId de la versión anterior y restáurala:

aws s3api copy-object \
  --bucket ccsoft-proyectosacc-frontend \
  --copy-source ccsoft-proyectosacc-frontend/index.html?versionId=<VERSION_ID> \
  --key index.html

Paso A3: Invalida la caché de CloudFront

aws cloudfront create-invalidation \
  --distribution-id <DISTRIBUTION_ID> \
  --paths "/*"

Paso A4: Verifica el frontend

Abre https://sacc.ccsoft.mx y confirma que la interfaz anterior ha vuelto.

---

PARTE B: Rollback de la API en la EC2

Si el problema es del backend (errores 500, API caída, etc.), restaura la API.

Paso B1: Conéctate al servidor EC2

ssh -i ~/.ssh/tu_llave.pem ubuntu@<IP_DE_LA_EC2>

Paso B2: Cambia al usuario thoth

sudo su - thoth

Paso B3: Ve al directorio de artefactos

cd /home/thoth/deploy/artifacts

Paso B4: Revisa los backups disponibles

ls -lah backup/

Verás algo como:

proyectosacc-app-20260414_103000.jar
proyectosacc-app-20260413_154500.jar

Cada archivo tiene una fecha y hora en su nombre.

Paso B5: Identifica cuál es la versión anterior estable

Normalmente es el backup más reciente antes del deploy fallido.

# Ordena por fecha para ver el más reciente
ls -lt backup/ | head -5

Paso B6: Detén el servicio actual

sudo systemctl stop proyectosacc-app.service

Paso B7: Reemplaza el archivo actual con el backup

# Guarda una copia del archivo fallido (por si necesitas investigarlo después)
mv current/proyectosacc-app.jar current/proyectosacc-app.jar.fallo-$(date +%Y%m%d_%H%M%S)

# Copia el backup al directorio current
cp backup/proyectosacc-app-20260414_103000.jar current/proyectosacc-app.jar

💡 Tip: reemplaza 20260414_103000 con la fecha real del backup que quieres restaurar.

Paso B8: Recarga systemd y reinicia el servicio

sudo systemctl daemon-reload
sudo systemctl start proyectosacc-app.service

Paso B9: Verifica que el servicio esté corriendo

sudo systemctl status proyectosacc-app.service

Debe decir active (running).

Paso B10: Ejecuta el health check

curl http://localhost:8080/actuator/health

Debe responder:

{"status":"UP"}

Paso B11: Verifica la API desde fuera

curl https://sacc.ccsoft.mx/api/actuator/health

Si todo funciona, el rollback fue exitoso.

---

4. Cómo verificar que el rollback funcionó

Checklist de verificación (API)

• El servicio systemd está en estado active (running).
• El health check responde "status":"UP".
• El endpoint https://sacc.ccsoft.mx/api/actuator/health responde sin errores.
• Los usuarios pueden iniciar sesión y usar la aplicación.
• No hay errores críticos recientes en los logs.

Checklist de verificación (Frontend)

• La página https://sacc.ccsoft.mx carga sin errores.
• La invalidación de CloudFront se completó.
• No hay errores de consola del navegador relacionados con assets faltantes.

Comandos útiles para verificar

# Estado del servicio API
sudo systemctl status proyectosacc-app.service

# Health check local
curl -s http://localhost:8080/actuator/health | grep '"status"'

# Health check remoto
curl -s https://sacc.ccsoft.mx/api/actuator/health | grep '"status"'

# Últimos logs
tail -n 30 /var/log/proyectosacc/proyectosacc-app/proyectosacc-app-service.log

# Verificar que Nginx sigue redirigiendo bien la API
sudo systemctl status nginx

# Verificar invalidación de CloudFront
aws cloudfront list-invalidations --distribution-id <DISTRIBUTION_ID>

---

5. Después del rollback

Una vez que la versión anterior esté estable:

1. Investiga qué falló en la nueva versión.
2. Revisa los logs del intento fallido.
3. Notifica al equipo por Telegram o el canal de comunicación que usen.
4. Corrige el problema en el código.
5. Haz un nuevo deploy solo cuando estés seguro de que el error está corregido.

Mensaje de notificación sugerido

🚨 Rollback ejecutado en proyectosacc
Motivo: [describe brevemente el problema]
Estado actual: Aplicación estable con versión anterior
Próximo paso: Investigación del error en la nueva versión

---

Anterior: 09-runbook-deploy.md
Siguiente: 11-checklist-primer-deploy.md