El CI/CD es la columna vertebral técnica de DevOps. Es el conjunto de prácticas que automatizan el camino entre «el código escrito por un desarrollador» y «la aplicación que corre en producción».
| Sigla | Nombre | En una frase |
|---|---|---|
| CI | Integración continua (Continuous Integration) | Se fusiona y se prueba el código a menudo y automáticamente. |
| CD | Entrega continua (Continuous Delivery) | El código probado está siempre listo para desplegarse (puesta en prod manual). |
| CD | Despliegue continuo (Continuous Deployment) | El código probado sale automáticamente a producción. |
Sin CI/CD, entregar un software se parece a una mudanza a mano: lento, cansado y arriesgado. Con CI/CD, es una cinta transportadora automatizada: pones el código en un extremo, la aplicación llega lista al otro.
🔧 Mini-ejercicio — Relaciona cada sigla con su definición: (1) CI, (2) Continuous Delivery, (3) Continuous Deployment.
(1) CI = fusión + build + pruebas automáticas frecuentes. (2) Continuous Delivery = siempre listo para desplegar, botón manual para prod. (3) Continuous Deployment = puesta en prod automática tras pruebas exitosas.
La integración continua consiste en fusionar con frecuencia el código de todos los desarrolladores en una rama común, y validar automáticamente cada fusión con un build y pruebas.
| Sin CI | Con CI |
|---|---|
| Se fusiona todo a fin de mes → conflictos grandes y dolorosos | Se fusiona varias veces al día → conflictos pequeños y fáciles |
| Los bugs se descubren tarde | Los bugs se descubren en minutos |
| «Funcionaba en mi máquina» | Build reproducible en el servidor |
Analogía: ordenar la cocina sobre la marcha (CI) en vez de esperar a que todo esté sucio (integración «big bang»). El pequeño esfuerzo frecuente evita la catástrofe rara.
🔧 Mini-ejercicio — Un desarrollador guarda su código 3 semanas sin fusionarlo, luego intenta un merge grande. ¿Qué principio de integración continua no respetó, y qué consecuencia es probable?
No fusionó con frecuencia. Consecuencia probable: un conflicto de fusión masivo y difícil de resolver, y bugs detectados muy tarde. La CI recomienda fusiones pequeñas y frecuentes.
Los dos «CD» se parecen pero diferencian en un solo punto: quién pulsa el botón de puesta en producción.
| Continuous Delivery | Continuous Deployment | |
|---|---|---|
| Puesta en producción | Manual (un humano hace clic) | Automática |
| Control | Decisión final humana | Ninguna intervención |
| Ideal para | Sectores regulados, releases planificados | Equipos maduros, alta tasa de pruebas |
Continuous Delivery = el coche está aparcado delante de la puerta, listo, llaves puestas; tú decides cuándo arrancar. Continuous Deployment = el coche autónomo arranca solo en cuanto está listo.
🔧 Mini-ejercicio — Un banco quiere que cada puesta en producción la apruebe un responsable. ¿Qué «CD» elegir?
Continuous Delivery: el pipeline deja la versión lista automáticamente, pero la puesta en producción sigue siendo una decisión humana (validación del responsable).
Un pipeline es una sucesión de etapas automatizadas (llamadas stages) que transforman el código fuente en aplicación desplegada. Si una etapa falla, el pipeline se detiene y se notifica al equipo.
| Stage | Rol | Ejemplo de herramienta |
|---|---|---|
| Checkout | Recuperar el código desde Git | Git |
| Build | Compilar / ensamblar | Maven, npm, javac |
| Test | Verificar automáticamente | JUnit, pytest |
| Package | Producir un artefacto entregable | .jar, imagen Docker |
| Staging | Desplegar en preproducción | servidor de prueba |
| Deploy | Poner en producción | servidor / cloud |
El principio del «fail fast»: se colocan las etapas rápidas y baratas (compilación, pruebas unitarias) primero. No sirve desplegar si el código ni siquiera compila.
🔧 Mini-ejercicio — ¿En qué orden colocar estos stages: Deploy, Build, Test, Checkout?
Checkout → Build → Test → Deploy. Se recupera el código, se compila, se prueba, y solo se despliega si todo está verde.
Sigamos el recorrido de una sola línea de código corregida por una desarrolladora, Léa, en una aplicación web.
Desarrollo paso a paso:
git push.v1.4.1.Compara: antes del CI/CD, esa misma corrección habría pedido una puesta en producción planificada, un atardecer, a mano, con el estrés de «ojalá funcione». Aquí, es una rutina de 6 minutos.
🔧 Mini-ejercicio — En la etapa 3, 2 pruebas de 124 fallan. ¿Qué hace el pipeline, y la versión sale a producción?
El pipeline se detiene en el stage Test, notifica a Léa y no despliega. La producción se queda en la versión estable anterior. Es el principio «fail fast» que protege la prod.
| Ventaja | Lo que cambia en concreto |
|---|---|
| Menos errores humanos | Las tareas repetitivas están en scripts: se acaba el olvido de un paso |
| Feedback rápido | Se sabe en minutos si un cambio rompe algo |
| Despliegues frecuentes | Se puede entregar varias veces al día con confianza |
| Reproducibilidad | Cada build es idéntico — se acabó el «funciona en mi máquina» |
| Trazabilidad | Cada cambio queda registrado: quién, qué, cuándo |
Cuanto más a menudo se despliega, más pequeño es cada despliegue, y por tanto menos arriesgado. Es contraintuitivo: desplegar más a menudo hace los despliegues más seguros, no más peligrosos.
🔧 Mini-ejercicio — Cita dos razones por las que desplegar 10 veces al día pequeños cambios es menos arriesgado que un solo despliegue grande al mes.
Question 1: ¿Qué significa «CI»?
a) Code Inspection
b) Continuous Integration
c) Container Initialization
d) Central Infrastructure
✅ Respuesta: b) — Continuous Integration: fusión y validación automáticas frecuentes del código.
Question 2: ¿Cuál es la diferencia entre Continuous Delivery y Continuous Deployment?
a) Ninguna, son sinónimos
b) En Delivery la puesta en prod es manual; en Deployment es automática
c) El Deployment no hace pruebas
d) La Delivery despliega automáticamente
✅ Respuesta: b) — Los dos preparan una versión lista; solo la puesta en producción difiere (manual vs automática).
Question 3: ¿Qué ocurre si el stage Test falla en un pipeline?
a) El pipeline continúa de todos modos hasta producción
b) El pipeline se detiene y se notifica al equipo
c) El código se borra del repositorio
d) El pipeline vuelve a empezar en bucle infinito
✅ Respuesta: b) — Principio «fail fast»: un fallo detiene el pipeline y dispara una alerta; nada sale a producción.
Question 4: ¿Qué es un artefacto en un pipeline?
a) Un bug introducido por error
b) El resultado empaquetado de un build (ej. un .jar, una imagen)
c) Un mensaje en los registros
d) Un usuario del sistema
✅ Respuesta: b) — El artefacto es el entregable producido por el build, listo para desplegarse.
Question 5: ¿Por qué desplegar a menudo hace los despliegues más seguros?
a) Porque cada despliegue es más pequeño y por tanto más fácil de diagnosticar y anular
b) Porque se suprimen las pruebas
c) Porque los servidores se vuelven más potentes
d) Porque los usuarios no se dan cuenta
✅ Respuesta: a) — Cambios pequeños y frecuentes reducen la superficie de riesgo y facilitan el rollback.
Un equipo desarrolla una aplicación Java. Diseña (en papel / en pseudo-pipeline) los stages de un pipeline CI/CD para esta aplicación, indicando para cada stage: su nombre, su rol, y qué debe detener el pipeline. Precisa también si recomiendas Continuous Delivery o Continuous Deployment, y por qué.
| Orden | Stage | Rol | Condición de parada |
|---|---|---|---|
| 1 | Checkout | Recuperar el código desde Git | Repositorio inaccesible |
| 2 | Build | Compilar con Maven (mvn package) | Error de compilación |
| 3 | Test | Lanzar las pruebas JUnit | Una prueba falla |
| 4 | Package | Producir el artefacto .jar / imagen | Fallo de empaquetado |
| 5 | Staging | Desplegar en preproducción | Arranque de la aplicación KO |
| 6 | Deploy | Poner en producción | Validación manual rechazada |
Elección recomendada para empezar: Continuous Delivery.
Justificación: mientras la cobertura de pruebas no esté madura, se mantiene una validación humana antes de producción (Delivery). Cuando el equipo confía en sus pruebas automatizadas, puede pasar a Continuous Deployment (puesta en prod automática).
Esquema esperado:
Lección 04 — Estrategias de despliegue: cómo pasar de la v1 a la v2 en producción sin romper el servicio (Blue/Green, Canary, Rolling…).
Todos los derechos reservados. Toda reproducción, difusión, uso o adaptación de este curso, en todo o en parte, está estrictamente prohibida sin la autorización escrita previa del Dr. Haythem REHOUMA.
Curso creado por Dr. Haythem REHOUMA — Desarrollo y despliegue de soluciones de datos