# 06 - Scripts de Despliegue

> Qué hace cada script y cuándo se ejecuta.

---

## 1. ¿Qué son los scripts de despliegue?

Los **scripts** son archivos de texto con instrucciones que la computadora puede ejecutar automáticamente.

En `proyectosacc` usamos scripts escritos en **Bash** (el lenguaje de comandos de Linux). Todos comienzan con esta línea mágica:

```bash
set -euo pipefail
```

Esto significa tres cosas:
1. **`set -e`**: Si un comando falla, el script se detiene inmediatamente.
2. **`set -u`**: Si usas una variable que no existe, el script se detiene.
3. **`set -o pipefail`**: Si un comando dentro de una "tubería" (`|`) falla, el script también se detiene.

> 💡 **En palabras simples**: es como poner el cinturón de seguridad antes de manejar.

---

### 1.1. Scripts provenientes de otros proyectos CI/CD

`proyectosacc` reutiliza scripts y utilerías que viven en repositorios compartidos:

- **`ci-cd-commons`**: contiene `telegram_alert.sh`, `logger_bash.sh` y otras utilerías base que usan todos los pipelines de la empresa.
- **`ci-cd-saac4`**: provee módulos de Terraform y scripts de despliegue adaptados para la familia SACC.

Estos repositorios se clonan dentro de la carpeta `/home/thoth/deploy/` (por ejemplo, `/home/thoth/deploy/ci-cd-commons/`) para que los scripts locales puedan usarlos.

### 1.2. Nuevo script: `deploy-frontend-s3.sh`

Este script se ejecuta **desde el pipeline de Bitbucket** (no dentro de la EC2). Su trabajo es subir el frontend React a S3.

Qué hace:
1. Sincroniza la carpeta `build/` con el bucket S3 (`aws s3 sync build/ s3://bucket-name --delete`).
2. Espera a que la sincronización termine.

> 💡 **Nota**: la invalidación de la caché de CloudFront se hace en el **paso 7** del pipeline (`07_deploy`), después de confirmar que la API está saludable. Así evitamos refrescar el frontend antes de que el backend esté listo.

Ejemplo de comando:
```bash
bash /home/thoth/deploy/scripts/deploy-frontend-s3.sh
```

---

## 2. `deploy.sh`

### ¿Qué hace?
Este es el script principal de despliegue de la **API backend**. Se ejecuta **dentro del servidor EC2** y se encarga de instalar la nueva versión del servicio.

### Pasos que sigue
1. **Crear directorios**: verifica que existan las carpetas necesarias (`backup`, `current`, `pids`, `logs`).
2. **Detener servicio anterior**: si la aplicación ya está corriendo, la detiene con `systemctl`.
3. **Configurar systemd**: crea o actualiza el archivo de servicio para que la app inicie automáticamente.
4. **Recargar systemd**: ejecuta `sudo systemctl daemon-reload`.
5. **Iniciar servicio**: ejecuta `sudo systemctl start <nombre-del-servicio>`.
6. **Health check**: hace peticiones a `http://localhost:8080/actuator/health` para verificar que la app responde.
7. **Guardar PID**: anota el ID del proceso para poder monitorearlo después.

### ¿Cuándo se llama?
- En el **paso 7** del pipeline (`07_deploy`).
- También puede ejecutarse manualmente si necesitas hacer un despliegue fuera del pipeline.

### Ejemplo de comando
```bash
bash /home/thoth/deploy/setup/deploy.sh
```

---

## 3. `health-check.sh`

### ¿Qué hace?
Verifica que la aplicación esté viva y respondiendo correctamente.

### Cómo funciona
1. Intenta conectarse a la URL de salud de la aplicación:
   ```
   http://localhost:8080/actuator/health
   ```
2. Si la respuesta contiene `"status":"UP"`, todo está bien.
3. Si no responde después de varios intentos, reporta un error.

### ¿Cuándo se llama?
- **Dentro de `deploy.sh`**, inmediatamente después de iniciar el servicio.
- También puede usarse manualmente para revisar si la app sigue funcionando horas después del despliegue.

### Ejemplo de comando manual
```bash
bash /home/thoth/deploy/scripts/health-check.sh
```

---

## 4. `rollback.sh`

### ¿Qué hace?
Regresa la API backend a la versión anterior si el nuevo despliegue falló. También puede restaurar el frontend en S3 si se habilitó **versionamiento de objetos** en el bucket.

### Pasos que sigue (API en EC2)
1. Busca el último backup en la carpeta `/home/thoth/deploy/artifacts/backup/`.
2. Detiene el servicio actual.
3. Copia el backup a la carpeta `current`.
4. Reinicia el servicio con la versión anterior.
5. Ejecuta un health check para confirmar que la versión anterior todavía funciona.

### Pasos que sigue (frontend en S3)
Si el frontend también necesita rollback:
1. Identifica la versión anterior del archivo en S3 usando el versionamiento del bucket.
2. Restaura la versión anterior de `index.html` y los assets estáticos.
3. Invalida la caché de CloudFront para que los usuarios vean la versión anterior.

### ¿Cuándo se llama?
- Cuando el `deploy.sh` o el `health-check.sh` reportan un fallo en la API.
- Manualmente, si descubres que la nueva versión del frontend o la API tiene un bug grave.

### Ejemplo de comando
```bash
bash /home/thoth/deploy/scripts/rollback.sh
```

---

## 5. `notify-telegram.sh`

### ¿Qué hace?
Envía mensajes a un grupo o chat de Telegram para informar sobre el estado del pipeline.

### Qué tipo de mensajes envía
- 🟢 **Éxito**: "El despliegue de proyectosacc terminó correctamente."
- 🔴 **Error**: "El pipeline de proyectosacc falló en el paso 4. Revisar logs."
- 🟡 **Advertencia**: "Health check falló. Iniciando rollback automático."

### ¿Cuándo se llama?
- Al **inicio** del pipeline.
- Al **final** del pipeline (éxito o fracaso).
- Cuando ocurre un error en cualquier paso.

### Variables necesarias
```bash
TELEGRAM_BOT_TOKEN=<token-del-bot>
TELEGRAM_CHAT_ID=<id-del-chat>
```

### Ejemplo de comando
```bash
bash /home/thoth/deploy/ci-cd-commons/telegram_alert.sh "Despliegue exitoso"
```

---

## 6. Resumen de cuándo usar cada script

| Script | ¿Cuándo se ejecuta? | ¿Dónde corre? |
|--------|---------------------|---------------|
| `deploy-frontend-s3.sh` | Paso 5 del pipeline (subir React a S3) | Pipeline (Bitbucket) |
| `deploy.sh` | Paso 7 del pipeline (desplegar API en la EC2), o manualmente | Dentro de la EC2 |
| `health-check.sh` | Después de `deploy.sh`, o manualmente | Dentro de la EC2 |
| `rollback.sh` | Cuando `deploy.sh` o `health-check.sh` fallan, o manualmente | Pipeline o EC2 |
| `notify-telegram.sh` | Inicio, fin o error del pipeline | Pipeline (Bitbucket) o EC2 |

---

## 7. Dato extra: ¿dónde viven los scripts?

En el servidor EC2, los scripts se organizan así:

```
/home/thoth/deploy/
├── artifacts/
│   ├── backup/          ← versiones anteriores de la API
│   ├── current/         ← versión activa de la API
│   ├── logs/            ← logs del pipeline
│   └── pids/            ← archivos con el ID de proceso
├── ci-cd-commons/
│   ├── telegram_alert.sh
│   └── logger_bash.sh
├── scripts/
│   ├── deploy-frontend-s3.sh   ← sube React a S3
│   ├── health-check.sh
│   └── rollback.sh
└── setup/
    └── deploy.sh               ← script principal del pipeline para la API (llamado vía SSH)
```

> 💡 **Nota**: el artefacto de la API que termina en `artifacts/current/` se descarga desde **Amazon S3** durante el paso de instalación del pipeline. No se transfiere directamente por SSH. El frontend React se sube directamente a S3 desde el pipeline.

---

*Anterior: [`05-pipeline-bitbucket.md`](05-pipeline-bitbucket.md)*  
*Siguiente: [`07-terraform-iac.md`](07-terraform-iac.md)*
