Cómo crear pipelines declarativos en Jenkins

Configurar pipelines declarativos en Jenkins aporta control con código, trazabilidad y métricas claras. Sin depender de la interfaz visual, se define un Jenkins file que usa agent any, tools con Node.js, options con timeout de 2 minutos y stages separados para instalación y pruebas. Además, se conecta a un repositorio remoto con GitHub trigger y se valida la versión de Node en el global config para evitar fallos.

¿Por qué usar un pipeline declarativo en Jenkins?

El enfoque declarativo permite versionar el job como código, evitando configuraciones manuales. Jenkins ofrece dos estilos: scripted pipeline y declarative pipeline. Aquí se trabaja con el declarativo, que facilita una estructura clara y validaciones desde el inicio.

• Configurar con código, no con interfaz visual. Menos errores manuales.
• Ejecutar en cualquier agente con Agent any cuando no hay slaves definidos.
• Gestionar herramientas con tools y el plugin de Node.js para fijar la versión deseada.
• Controlar tiempos con options y timeout de 2 minutos.
• Dividir en etapas con stages y steps para medir, depurar y optimizar.

¿Cómo se estructura el Jenkins file del ejemplo?

Se declara un pipeline con secciones al top level (en la root) y luego los stages. Se separa en dos pasos: instalación de dependencias con CD al directorio correspondiente y NPM install, y luego run test. Esta separación permite saber cuánto toma cada parte y dónde optimizar.

pipeline {
  agent any

  tools {
    nodejs 'Node 11.0.0'
  }

  options {
    timeout(time: 2, unit: 'MINUTES')
  }

  stages {
    stage('Instalar dependencias') {
      steps {
        sh 'cd Jenkins && npm install'
      }
    }
    stage('Run test') {
      steps {
        sh 'npm test'
      }
    }
  }
}

• agent any: ejecuta en cualquier agente disponible.
• tools: selecciona la versión de Node.js requerida.
• options > timeout: corta la ejecución a los 2 minutos si se excede.
• stages: instala dependencias y ejecuta pruebas en pasos separados.

¿Cómo conectar el pipeline con GitHub y ejecutarlo?

Al crear un nuevo job tipo pipeline (por ejemplo, “test pipeline sum node”), se configura el origen del script en un repositorio remoto. Se activa el GitHub trigger, se indica la URL de git y se seleccionan todos los branches, no solo master. Si el Jenkins file está en un subdirectorio (por ejemplo, “Jenkins test”), se especifica esa ruta en el pipeline block.

• Crear en Jenkins: New item > tipo pipeline.
• Activar GitHub trigger para escuchar cambios.
• Configurar git con el repositorio público: sin credenciales.
• Seleccionar todos los branches: no solo master.
• Indicar el directorio donde está el Jenkins file.
• Guardar y preparar el entorno antes de ejecutar.

Antes de correr, validar en el global config que la instalación de Node.js tenga el nombre y versión usados en tools. El ejemplo pide “Node 11.0.0”. Si no existe (por ejemplo, si solo está “11.1.0” o si cambiaste el prefijo a “node”), el build fallará. Tras ajustar, usar Build now.

¿Qué ventajas dan los stages y el stage view?

El stage view muestra tiempos por etapa y facilita la depuración. Se observan duraciones como: bajar código de GitHub en 290 ms, preparar node en 88 ms, instalar dependencias en 1 s y correr pruebas en 1 s. Esta visibilidad no se obtiene en un freestyle job.

• Ver qué parte tomó más tiempo. Optimizar con datos.
• Identificar fallos por etapa: solo el stage problemático se marca en rojo.
• Revisar console output con secciones: with env, sh y comandos más claros.
• Evitar búsquedas largas: no “se rompió el job”, sino “se rompió en dependencies”.

¿Te gustaría ver otras prácticas para organizar stages o trucos con console output? Deja tus preguntas o experiencias en los comentarios.