Proyecto final: una cadena DevOps completa del commit a producción

Lo que vas a aprender en este TP

• Encadenar CI, seguridad y GitOps
• Verificar y volver atrás automáticamente
• Medir la cadena con DORA

Introducción #

Lo que vas a aprender en esta sección

• Encadenar CI, seguridad y GitOps
• Verificar y volver atrás automáticamente
• Medir la cadena con DORA

Contexto. Presentas a tu dirección una cadena de entrega de principio a fin para un nuevo servicio. Cada paso reutiliza una práctica del curso; el objetivo es encadenarlas sin intervención manual entre el commit y el clúster.

Requisitos previos: una cuenta de GitHub, Docker, kubectl y kind; haber hecho las prácticas de Git, CI/CD, GitOps y DevSecOps  ·  Duración estimada: 120 min

Un commit en main llega a producción en pocos minutos, de forma verificada, trazable y reversible.

Puesta en práctica #

Pasos guiados, con su corrección.

1. 1. Dos repositorios

   ¿Por qué? Separar el código y la descripción del despliegue da permisos e historiales distintos.

   Crea shop-api (código, Dockerfile, pruebas, workflow) y shop-deploy (manifiestos Kustomize base y overlays/staging, overlays/production). Protege main en ambos.

2. 2. Pipeline CI

   ¿Por qué? El pipeline aplica las lecciones del capítulo CI/CD: fallar pronto, construir una vez, asegurar.

   En shop-api, escribe un workflow: lint y pruebas, Gitleaks y Trivy, build y push a GHCR etiquetado con el SHA, SBOM y firma Cosign sin clave.

3. 3. Actualización automática del repositorio de despliegue

   ¿Por qué? La CI solo necesita escribir en Git: no tiene ningún acceso al clúster.

   Añade un job que actualice la etiqueta de staging en shop-deploy con kustomize edit set image y haga push del commit (token con permisos limitados o GitHub App).

4. 4. Despliegue GitOps

   ¿Por qué? Argo CD aplica cada commit del repositorio de despliegue y corrige cualquier deriva.

   En un clúster kind con Argo CD (práctica GitOps), crea dos Applications shop-staging y shop-production que apunten a los overlays, con sincronización automática.

5. 5. Verificar y promover

   ¿Por qué? Producción recibe exactamente la imagen validada en staging, mediante una pull request revisada.

   Tras sincronizar staging, lanza un smoke test; si pasa, abre automáticamente una pull request que copie la misma etiqueta al overlay de producción.

6. 6. Incidente y vuelta atrás

   ¿Por qué? Una vuelta atrás mediante Git es rápida, trazable y no requiere acceso al clúster.

   Entrega una versión que devuelva errores 500 en /health, comprueba que el smoke test de staging falla (sin promoción), simula un incidente en producción y vuelve atrás con git revert en shop-deploy. Redacta un breve post-mortem.

7. 7. Medir

   ¿Por qué? Las métricas DORA muestran si la cadena cumple lo prometido.

   Despliega cinco pequeños cambios y calcula la frecuencia de despliegue, el plazo commit → producción, la tasa de fallos y el tiempo de restauración (método de la práctica DORA). Presenta el resultado y la próxima mejora.

Nivel de dificultad : ●●●●○ (4/5)