Despliegue y Rollback

Despliegue y Rollback

Kairo se despliega automáticamente en OCI (Oracle Kubernetes Engine) cada vez que se fusiona un cambio a la rama master. Si un deploy introduce un problema, existe un mecanismo de rollback que revierte al estado anterior sin necesidad de tocar la infraestructura directamente.

---

Pipeline de despliegue automático (CD)

El flujo normal de un cambio es:

PR aprobado → merge a master → CI pasa → CD se dispara → nueva imagen en OCIR → kubectl set image → app actualizada

Paso	Qué ocurre
CI (pruebas)	Se ejecutan tests de backend y frontend. Si fallan, el CD no se dispara.
Build de imagen	Se construye la imagen Docker tageada con los primeros 7 caracteres del commit SHA (ej. a1b2c3d).
Push a OCIR	La imagen se sube al registry de OCI (mx-queretaro-1.ocir.io).
Deploy a OKE	kubectl set image actualiza el deployment en el clúster de Kubernetes.
Verificación	kubectl rollout status espera hasta 180s a que el deployment esté listo.

Cada deploy exitoso crea una nueva revisión en el historial de Kubernetes.

---

Rollback al deploy anterior

El workflow de rollback permite revertir al deploy anterior con un solo clic desde GitHub, sin editar código ni conectarse a OCI.

Cómo ejecutarlo

1. Ve al repositorio en GitHub
2. Haz clic en la pestaña Actions
3. Selecciona el workflow Rollback en el panel izquierdo
4. Haz clic en Run workflow → Run workflow

El workflow ejecuta kubectl rollout undo, que instruye a Kubernetes a restaurar la revisión anterior del deployment.

Warning

El rollback revierte siempre al deploy inmediatamente anterior, no a un commit específico. Ver la sección Comportamiento del historial para entender las implicaciones.

Tip

No es necesario recompilar nada. La imagen del deploy anterior ya existe en OCIR y Kubernetes la tiene referenciada en su historial de revisiones.

---

Comportamiento del historial

Kubernetes mantiene un historial de revisiones numeradas. Cada deploy exitoso añade una revisión nueva.

Escenario 1 — Rollback simple

commit A (rev 1) → commit B con bug (rev 2) → Rollback → commit A (rev 3)

El rollback despliega la imagen del commit A. Kubernetes crea una revisión 3 que apunta a la misma imagen que la revisión 1.

Escenario 2 — Deploy nuevo después de un rollback

commit A (rev 1) → commit B (rev 2) → Rollback → commit A (rev 3) → commit C (rev 4)
                                                                           ↓
                                                                      Rollback → commit A (rev 3) ✓

Hacer rollback desde el commit C lleva de vuelta al commit A, porque era el deploy que estaba activo justo antes del commit C.

Escenario 3 — Dos deploys sin rollback intermedio

commit A (rev 1) → commit B (rev 2) → commit C (rev 3)
                                            ↓
                                       Rollback → commit B (rev 2) ← no commit A

Warning

Si se hacen dos deploys consecutivos con problemas y se ejecuta rollback una sola vez, se regresa al deploy intermedio (commit B), no al inicial (commit A). Para retroceder más pasos sería necesario volver a ejecutar el rollback.

---

Implementación técnica

El rollback está definido en .github/workflows/rollback.yml:

• Trigger: workflow_dispatch (manual, desde GitHub Actions)
• Environment: production (requiere los mismos secrets que el CD)
• Secret requerido: KUBECONFIG_DATA — configuración del clúster OKE en base64
• Comando central: kubectl rollout undo deployment/todolistapp-springboot-deployment -n mtdrworkshop
• Verificación: kubectl rollout status con timeout de 180 segundos

No requiere checkout del código ni reconstruir la imagen Docker.