Curso CI/CD

Arrancamos con una visión general de qué es CI/CD y qué problemas reales busca resolver (tiempo de entrega, riesgo, retrabajo). Se explica la dinámica del curso: trabajo en grupos, tareas entre clases y revisión breve al inicio de cada sesión. Presentamos el proyecto guía ya armado (el “sistema sobre el que vamos a trabajar”) y dejamos listo el entorno: cuentas, repositorios, acceso a herramientas y una primera corrida end-to-end para que todos partan de una base común. También introducimos Accelerate como marco de referencia para medir y mejorar.

En esta clase ponemos el foco en qué condiciones mínimas necesita un sistema para soportar despliegues frecuentes. Hablamos de calidad como habilitador (no como “perfeccionismo”): pruebas automatizadas, diseño que facilite cambios, y decisiones de arquitectura que impactan directamente en la capacidad de integrar y desplegar sin drama. La idea es bajar a tierra por qué CI/CD se vuelve frágil cuando el software está acoplado, no es testable o depende de pasos manuales.

Introducimos las 4 métricas de Accelerate (DORA) como lenguaje común para evaluar performance de entrega: lead time, frecuencia de despliegue, change failure rate y MTTR. No es una clase “de indicadores” aislada: la usamos para entender qué vamos a optimizar durante el curso y cómo evitar métricas vanidosas. Se deja lectura asignada del libro y se define cómo vamos a observar estas métricas (aunque sea de forma aproximada) sobre el proyecto guía.

Nos metemos en testing con criterio de entrega continua: qué tipos de pruebas convienen (unitarias, integración, arquitectura) y por qué el objetivo es reducir la incertidumbre rápidamente. Vemos cómo una estrategia de tests mal planteada puede frenar el delivery (tests lentos, frágiles, duplicados) y cómo construir un set mínimo que actúe como red de seguridad real para integrar cambios con frecuencia.

Analizamos qué características arquitectónicas facilitan CD: bajo acoplamiento, separación de responsabilidades, límites claros entre componentes y evolución segura del sistema. Introducimos el concepto de compatibilidad hacia atrás (API/DB) como requisito práctico, no teórico, y cómo pensar la modularidad con una mirada medible (métricas de componentes, dependencias, puntos de fricción). La clase busca que el alumno conecte arquitectura con capacidad de desplegar seguido.

Construimos la idea de “pipeline” como mecanismo de feedback y control de riesgo, no como un script. Vemos buenas prácticas: stages, separación CI/CD, artefactos, promoción, trazabilidad, y gates de calidad. Luego aterrizamos esto en el proyecto guía: cómo se automatiza el despliegue a un entorno (staging) y cómo se valida post-deploy (smoke tests / healthchecks) para evitar “deploy exitoso pero sistema roto”. (Si querés mantener un ecosistema Blazor/API/SQL/Mobile, acá se presenta como mapa general y se define qué parte es core y qué queda como extensión.)

Retomamos Accelerate con más detalle, pero ahora con contexto: conectamos prácticas concretas (branching, pruebas, automatización, despliegue, observabilidad) con impacto en métricas DORA. La intención es que el alumno entienda que los indicadores no son “reporting”, sino una forma de decidir qué mejorar primero. También discutimos limitaciones típicas al medir (qué se rompe cuando hay procesos manuales, ambientes inestables o releases grandes).

En esta sesión ampliamos el alcance: CD/CI no termina en “subir binarios”. Introducimos Infraestructura como Código para reducir variabilidad y dependencia de configuraciones manuales, y definimos un mínimo de observabilidad para operar: health/readiness, logs, métricas básicas y alertas. El objetivo es que el alumno vea el vínculo directo con MTTR y change failure rate: sin monitoreo, los errores se detectan tarde y se recupera lento.

Vemos qué prácticas de trabajo son coherentes con CI/CD: DevOps como enfoque socio-técnico, XP como origen de muchas prácticas técnicas (CI, TDD, refactoring, small releases) y Agile como marco de gestión. La idea no es “repasar metodologías”, sino entender qué comportamientos y restricciones organizacionales habilitan o bloquean el delivery continuo: tamaño de lote, gestión de WIP, definición de terminado, ownership, y cultura de aprendizaje.

Cerramos uniendo piezas que suelen quedar sueltas: feature flags, estrategias de branching (trunk-based vs variantes), semantic versioning, versionado de APIs, y migraciones seguras. También armamos un mapa de adopción realista: por dónde empezar en una organización, qué anti-patrones evitar (gates burocráticos, pipelines lentos, “CI siempre rojo”), y cómo sostener una mejora continua usando métricas. Esta clase funciona como síntesis: del concepto al plan aplicable.