CodeGym /Cursos /Módulo 5. Spring /Lección 141: Introducción a los procesos CI/CD

Lección 141: Introducción a los procesos CI/CD

Módulo 5. Spring
Nivel 22 , Lección 0
Disponible

Si alguna vez has trabajado en un equipo de desarrolladores (o al menos has visto memes sobre cómo los desarrolladores prueban y despliegan manualmente las aplicaciones un viernes por la noche), sabes el dolor de cabeza que puede suponer compilar, testear y desplegar aplicaciones. Ahí es cuando CI/CD aparece como un superhéroe.

CI/CD significa Continuous Integration (integración continua) y Continuous Deployment/Delivery (despliegue/entrega continua). Sí, son tres palabras, y sí, son dos conceptos — porque Deployment y Delivery a veces se distinguen y a veces se juntan.

Así que vamos a separarlos un poco:

Continuous Integration (CI):

Imagina que tu código es un rompecabezas gigante que montas con tus colegas. Cada vez que alguien añade su pieza, el sistema comprueba que encaje con las demás piezas y que no rompa lo ya montado. Eso es CI: el proceso de build y test automáticos después de cada cambio en el código. Te permite detectar errores antes de que se conviertan en un dolor de cabeza.

Continuous Deployment/Delivery (CD):

  • Continuous Deployment — es cuando tu código se envía automáticamente a los servidores de producción después de pasar todos los tests. Es como "Pulsé git push, y en 5 minutos todo está listo".
  • Continuous Delivery requiere solo un clic manual para lanzar el proceso de despliegue, y antes de eso todos los tests y comprobaciones ya se han realizado automáticamente. Es útil si quieres más control sobre el lanzamiento.

¿Por qué CI/CD es importante?

En resumen: CI/CD ahorra tiempo, nervios y dinero. Pero eso suena un poco abstracto, vamos a desglosarlo.

  1. Automatización de tareas rutinarias: te olvidas de ejecutar tests manualmente y de comprobar "¿esto funciona de verdad?". La máquina hace todo por ti.
  2. Detección temprana de errores: los tests se ejecutan después de cada cambio en el código. Si alguien "rompió producción", se detecta de inmediato y no después de un par de semanas.
  3. Llegar al mercado más rápido: puedes entregar nuevas features a los usuarios más rápido, porque las fases de build y test se aceleran muchísimo.
  4. Menos errores humanos: la gente se olvida. La gente se cansa. La gente comete errores tontos. Las máquinas no (bueno, casi no, si las configuras bien).

Etapas principales de un pipeline CI/CD

Vamos a ver de qué consta un pipeline típico de CI/CD. Es como una cadena de estaciones en una línea de montaje, cada una encargada de una fase de preparación de tu aplicación.

  1. Commit de cambios: los desarrolladores hacen cambios en el código y los envían al repositorio central (GitHub, GitLab, etc.).
  2. Build automático: en esta etapa tu código se compila, se empaqueta en un artefacto (por ejemplo, un archivo JAR o WAR) y se comprueba si se puede ejecutar.
  3. Testing:
    • Pruebas unitarias: verifican partes individuales del código.
    • Pruebas de integración: verifican la interacción entre componentes.
    • Pruebas End-to-End: verifican el funcionamiento de la aplicación completa.
  4. Despliegue en entorno de pruebas (staging): si los tests pasan con éxito, la aplicación se despliega en un servidor para comprobarla en condiciones lo más cercanas posible a producción.
  5. Despliegue en entorno de producción (production): tras las pruebas en staging puedes desplegar la aplicación para usuarios reales.

Ejemplos: ¿cómo funciona esto en la práctica?

Imagina que eres desarrollador. Así puede verse tu día con CI/CD:

  1. Hiciste cambios en el código y los pusheaste en GitLab.
  2. GitLab CI lanza el build automático de tu aplicación.
  3. Las pruebas unitarias comprueban que el nuevo código funciona correctamente.
  4. Si los tests pasan, la aplicación se despliega en un servidor de pruebas (staging) y puedes verificar que todo funciona.
  5. Con un par de clics (o automáticamente, si tienes Continuous Deployment configurado) la aplicación se despliega en production.

Ventajas de implementar CI/CD

Pasarse a CI/CD puede parecer complicado y laborioso, pero estas son las razones principales por las que merece la pena:

  1. Ahorro de tiempo: ya no tienes que ejecutar tests manualmente, compilar la aplicación o subir archivos al servidor.
  2. Mejora de la calidad del producto: gracias a la detección temprana de errores y al testing automático, tu código se vuelve más fiable.
  3. Velocidad de lanzamiento de actualizaciones: CI/CD permite a la empresa lanzar actualizaciones con más frecuencia y rapidez. Como dicen en la comunidad DevOps, "deploy early, deploy often".
  4. Estabilidad y repetibilidad: cada vez el pipeline ejecuta los mismos pasos. Nada de "factores humanos".

¿Por qué CI/CD se considera un estándar en la industria?

CI/CD no se convirtió en estándar por moda. Este enfoque ha demostrado su eficacia en empresas de todos los tamaños: desde startups trabajando en su primer producto hasta gigantes como Google y Netflix.

Dato interesante:

Netflix hace miles de deploys en production cada día. Eso solo fue posible gracias a CI/CD y a la automatización de procesos. Imagínate si todo eso se hiciera a mano — los ingenieros no dormirían.


Herramientas que estudiaremos

Hay muchas herramientas para configurar CI/CD. Aquí tienes algunas de las más populares con las que nos familiarizaremos:

  • Jenkins: una herramienta muy potente y flexible para construir pipelines. Aunque a veces parece que merece una medalla "por el UI más anticuado".
  • GitLab CI: herramienta CI/CD integrada para proyectos en GitLab. Cómoda, minimalista, con una potente configuración en YAML.
  • CircleCI: una herramienta simple y popular, especialmente entre los que usan Docker. Pero no está integrada con GitLab/GitHub, lo que puede ser un inconveniente para algunos.

Empezaremos con Jenkins y GitLab CI — dos herramientas que suelen elegirse para trabajar con aplicaciones Spring Boot.


Pregunta para discusión: "¿CI/CD es solo para empresas grandes?"

En absoluto. Imagina que estás desarrollando una pequeña tienda online. Cada vez que añades una nueva funcionalidad necesitas comprobar que nada se ha roto. Configurando CI/CD te liberas tiempo para trabajar en features, en vez de probar la aplicación manualmente.


Ahora que conoces la teoría, en las siguientes lecciones iremos a la práctica: crearemos nuestra propia aplicación Spring Boot, configuraremos un pipeline usando Maven y nos conectaremos a GitLab CI. ¡Es hora de automatizar las tareas aburridas!

Comentarios
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION