Cómo construir un pipeline de CI/CD desde cero: Guía para principiantes

Construye tu primer pipeline de CI/CD desde cero

Construir tu primer pipeline de CI/CD puede parecer una tarea abrumadora, especialmente cuando los sistemas del trabajo son complejos y arriesgados para experimentar. Sin embargo, los principios fundamentales son sorprendentemente sencillos: un pipeline es simplemente un proceso automatizado que instala dependencias, ejecuta pruebas y compila tu aplicación en un entorno limpio y reproducible. Esta guía te explicará los conceptos básicos y los pasos prácticos que necesitas para cómo construir un pipeline de CI/CD desde cero, transformando despliegues manuales propensos a errores en un flujo de trabajo automatizado y fiable.

No necesitas Kubernetes ni un sistema a escala de producción para practicar CI/CD. Empieza con un proyecto pequeño, un repositorio Git y una herramienta de CI como GitHub Actions, GitLab CI o Jenkins. El paso más crítico es asegurarte de que tu compilación sea reproducible localmente antes de escribir una sola línea de configuración del pipeline.

La base: la reproducibilidad es clave

Antes de escribir tu primer archivo de pipeline, tu proyecto debe poder compilarse desde cero. Si esto falla en un clon nuevo de tu repositorio, fallará en CI.

Paso 1: Haz que tu compilación local sea reproducible

La regla de oro es asegurarte de que tu aplicación se compile correctamente desde un estado limpio en tu máquina local. Por ejemplo:

• Node.js: npm ci && npm test && npm run build
• Python: pip install -r requirements.txt && pytest
• Go: go test ./... && go build

Paso 2: Confirma los archivos de bloqueo

Los archivos de bloqueo (como package-lock.json, go.sum o Pipfile.lock) son esenciales para compilaciones deterministas. Sin ellos, tu pipeline de CI podría instalar versiones de dependencias diferentes a las que usaste localmente, lo que provocaría fallos impredecibles en las pruebas. En Node.js, npm ci aplica exactamente el archivo de bloqueo, evitando esta "deriva de dependencias".

Escribiendo tu primer pipeline

Con una compilación reproducible, ya puedes automatizarla. Un pipeline básico tiene tres etapas: Compilación, Prueba y Despliegue.

Paso 3: Elige tu herramienta de CI/CD

Tu elección a menudo depende de dónde vive tu código. Aquí tienes tres opciones comunes:

Herramienta	Mejor para	Definición del pipeline	Opción autoalojada
GitHub Actions	Proyectos ya en GitHub, repos públicos (gratis).	.github/workflows/*.yml	Sí (runners autoalojados)
GitLab CI	Plataforma DevOps integral con alojamiento Git.	.gitlab-ci.yml	Sí (GitLab CE)
Jenkins	Altamente personalizable, ecosistema maduro, lógica de compilación compleja.	Jenkinsfile (Groovy)	Sí (vía Java, basado en plugins)

Paso 4: Crea una configuración mínima de pipeline

La definición del pipeline es un archivo YAML o Groovy en la raíz de tu repositorio que le indica al ejecutor de CI qué hacer.

Ejemplo: .gitlab-ci.yml (GitLab CI) Esto define un pipeline que compila una aplicación Go, guarda el binario como artefacto y luego lo ejecuta en una etapa posterior.

imagen predeterminada:
  imagen: golang

etapas:
  - compilar
  - ejecutar

compilar go:
  etapa: compilar
  script:
    - go build
  artefactos:
    rutas:
      - array

ejecutar go:
  etapa: ejecutar
  script:
    - ./array

Ejemplo: Jenkinsfile (Pipeline Declarativo) Esto hace lo mismo, usando una imagen Docker para ejecutar la aplicación Node.js.

pipeline {
    agente { docker { imagen 'node:20-alpine' } }
    etapas {
        etapa('Compilar') {
            pasos { sh 'npm ci && npm run build' }
        }
        etapa('Probar') {
            pasos { sh 'npm run test' }
        }
    }
}

⚠️ Advertencia de seguridad: Nunca codifiques variables de entorno como URLs de bases de datos o claves de API en tu repositorio. Usa el gestor de secretos integrado de tu herramienta de CI (Variables de GitLab CI, Credenciales de Jenkins o Secretos de GitHub Actions) para inyectarlas en tus trabajos.

Compartir datos entre etapas

Una característica clave de los pipelines modernos es la capacidad de compartir datos entre trabajos. Sin esto, tendrías que recompilar tu aplicación en cada etapa, desperdiciando tiempo y recursos.

Paso 5: Usa artefactos

Los artefactos son archivos o directorios guardados de un trabajo y puestos a disposición de trabajos posteriores. En el ejemplo de GitLab CI, el trabajo compilar go guarda el binario array. El trabajo ejecutar go descarga ese binario automáticamente, usándolo sin necesidad de recompilar.

Automatizando despliegues (opcional)

Una vez que CI funciona, puedes añadir despliegue continuo. El principio es simple: los despliegues solo deben ocurrir después de que las pruebas pasen.

Paso 6: Implementa una estrategia básica de despliegue

Para aplicaciones simples, un comando SSH puede copiar archivos a tu servidor.

Ejemplo: Desplegar con rsync

desplegar:
  etapa: desplegar
  imagen: alpine:latest
  solo:
    - main
  script:
    - apk add --no-cache openssh-client rsync
    - rsync -avz --delete dist/ deploy@tuserver:/var/www/app/

Si usas contenedores, la etapa de despliegue típicamente compila una imagen Docker, la sube a un registro y luego usa SSH para ejecutar docker compose pull && docker compose up -d en el servidor de producción.

Practicar y solucionar problemas

Leer sobre CI/CD no es suficiente. Para aprender de verdad, debes ejecutar pipelines y romperlos deliberadamente.

Paso 7: Rompe cosas intencionadamente para aprender

Aquí es donde ocurre la comprensión real. Prueba estos experimentos:

1. Elimina una declaración de dependencia. ¿Falla CI? ¿Por qué?
2. Borra el archivo de bloqueo. ¿Las derivas de versiones rompen la compilación?
3. Añade una prueba inestable. ¿Pasa localmente pero falla en CI? Esto a menudo expone diferencias en el entorno limpio de CI.

Paso 8: Usa informes de pruebas y registros

CI debe proporcionar visibilidad sobre qué pruebas fallaron, cuáles son lentas y cuáles son inestables. Usa los registros no solo para encontrar errores, sino para entender todo el proceso: ¿cuánto tiempo lleva la instalación de dependencias? ¿Dónde exactamente falla la compilación?

Preguntas frecuentes

¿Cuánto tiempo se tarda en construir mi primer pipeline de CI/CD? Para un proyecto simple, puedes tener un pipeline básico funcionando en menos de una hora. El laboratorio práctico de GitLab CI estima 15 minutos para un pipeline fundamental. El tiempo suele dedicarse a escribir el archivo de configuración y solucionar problemas de reproducibilidad.

¿Debería elegir Jenkins, GitHub Actions o GitLab CI para un principiante? Si tu código está en GitHub, GitHub Actions es una elección natural. Para una plataforma integral, GitLab CI es excelente. Jenkins es increíblemente potente pero tiene una curva de aprendizaje más pronunciada y requiere más mantenimiento, por lo que suele ser mejor para configuraciones más grandes y complejas.

¿Cuál es la diferencia entre un artefacto y una caché en CI/CD? Los artefactos se usan para pasar archivos entre etapas (por ejemplo, pasar un binario compilado de la etapa de compilación a la de despliegue). Las cachés se usan para acelerar las compilaciones reutilizando archivos como dependencias (node_modules) entre diferentes ejecuciones del pipeline.

¿Por qué mis pruebas pasan localmente pero fallan en el pipeline de CI? Esto suele ser una señal de deriva del entorno. Tu máquina local puede tener versiones de software o variables de entorno diferentes. Por eso es crucial confirmar los archivos de bloqueo y por qué ejecutar tu proyecto desde un clon limpio localmente es un primer paso necesario.

¿Necesito Docker para construir un pipeline de CI/CD? No estrictamente, pero es muy recomendable. Ejecutar trabajos dentro de contenedores Docker garantiza aislamiento y reproducibilidad. Asegura que cada trabajo se ejecute en un entorno limpio y conocido, evitando que los trabajos interfieran entre sí o contaminen el servidor anfitrión.

— Editorial Team