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`

```bash
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:

```bash
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

```bash
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

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

#### Paso B2: Cambia al usuario thoth

```bash
sudo su - thoth
```

#### Paso B3: Ve al directorio de artefactos

```bash
cd /home/thoth/deploy/artifacts
```

#### Paso B4: Revisa los backups disponibles

```bash
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**.

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

#### Paso B6: Detén el servicio actual

```bash
sudo systemctl stop proyectosacc-app.service
```

#### Paso B7: Reemplaza el archivo actual con el backup

```bash
# 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

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

#### Paso B9: Verifica que el servicio esté corriendo

```bash
sudo systemctl status proyectosacc-app.service
```

Debe decir `active (running)`.

#### Paso B10: Ejecuta el health check

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

Debe responder:
```json
{"status":"UP"}
```

#### Paso B11: Verifica la API desde fuera

```bash
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

```bash
# 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`](09-runbook-deploy.md)*  
*Siguiente: [`11-checklist-primer-deploy.md`](11-checklist-primer-deploy.md)*