Declarativo vs. Scriptado: Eligiendo la Sintaxis de tu Pipeline de Jenkins

Jenkins Pipeline te ofrece dos formas de escribir un Jenkinsfile: Declarativo y Scriptado. Ambos pueden construir, probar e implementar tu aplicación, pero te llevan a diferentes compensaciones en legibilidad, validación y flexibilidad de Groovy.

Si tu equipo está eligiendo una sintaxis para un nuevo pipeline, comienza con el flujo de trabajo que necesitarás mantener dentro de seis meses. Declarativo suele ser más fácil de leer y revisar. Scriptado te da un control más directo de Groovy cuando el pipeline realmente necesita un comportamiento dinámico.

Entendiendo los Pipelines de Jenkins

Antes de profundizar en las sintaxis, recordemos brevemente qué es un Pipeline de Jenkins. Un Pipeline es un conjunto de plugins que soporta la implementación e integración de pipelines de entrega continua en Jenkins. Es esencialmente una secuencia de pasos automatizados que definen todo el proceso de entrega de software, desde la confirmación del código hasta la implementación. Estos pasos se definen en un Jenkinsfile, típicamente escrito en Groovy, y ofrecen una forma poderosa de gestionar escenarios complejos de construcción, prueba e implementación.

Jenkins Pipeline as Code proporciona varias ventajas clave:

Control de Versiones: El Jenkinsfile se almacena en el control de fuentes, al igual que el código de la aplicación, permitiendo versionado, auditoría y colaboración.
Repetibilidad: Asegura una ejecución consistente del proceso de entrega en diferentes entornos y ejecuciones.
Visibilidad: Proporciona una vista clara y comprensible de todo el proceso de entrega.
Durabilidad: Los pipelines pueden sobrevivir a reinicios del maestro de Jenkins.
Extensibilidad: A través de bibliotecas compartidas, la lógica compleja puede ser abstraída y reutilizada.

Pipelines Declarativos

El Pipeline Declarativo es la sintaxis más nueva y opinada diseñada para facilitar la escritura y comprensión de pipelines. Proporciona un enfoque estructurado con bloques predefinidos, lo que ayuda a los equipos a mantener los Jenkinsfiles consistentes.

Características y Sintaxis

Los Pipelines Declarativos imponen una estructura específica definida por bloques de nivel superior como pipeline, agent, stages, steps, post, environment, parameters, options, triggers, tools, input y when. Esta estructura simplifica la definición del pipeline al proporcionar límites claros para diferentes partes del flujo de trabajo.

Aquí hay una estructura básica de un Pipeline Declarativo:

pipeline {
    agent any // O 'label', 'docker', etc.

    stages {
        stage('Build') {
            steps {
                echo 'Construyendo la aplicación...'
                sh 'mvn clean install'
            }
        }
        stage('Test') {
            steps {
                echo 'Ejecutando pruebas...'
                sh 'mvn test'
            }
        }
        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                echo 'Implementando en producción...'
                script {
                    // La lógica similar a Scripted se puede poner aquí si es absolutamente necesario
                    // Por ejemplo, llamar a una función de biblioteca compartida
                    // mySharedLibrary.deployApplication()
                }
            }
        }
    }

    post {
        always {
            echo 'Pipeline finalizado.'
        }
        success {
            echo '¡Pipeline exitoso!'
        }
        failure {
            echo 'Pipeline fallido.'
        }
    }
}

Ventajas de los Pipelines Declarativos

Simplicidad y Legibilidad: La estructura predefinida hace que los pipelines sean fáciles de leer y entender, incluso para no expertos. Se siente más como un archivo de configuración.
Enfoque Estructurado: Impone mejores prácticas y consistencia en todos los pipelines, reduciendo la curva de aprendizaje y el potencial de errores.
Características Integradas: Ofrece un rico conjunto de características integradas para patrones comunes de CI/CD, como ejecución condicional (when), acciones posteriores a la construcción (post), ejecución paralela de etapas y varias opciones para gestionar el flujo del pipeline.
Más Fácil de Aprender: Los desarrolladores sin un conocimiento extenso de Groovy pueden comenzar rápidamente debido a su sintaxis opinada.
Validación: Jenkins puede validar más de la estructura antes de la ejecución porque Declarativo tiene reglas más estrictas.

Limitaciones de los Pipelines Declarativos

Menos Flexible: La estructura rígida puede ser restrictiva para flujos de trabajo altamente complejos o dinámicos que requieren lógica Groovy personalizada fuera de los bloques predefinidos.
Acceso Directo Limitado a Groovy: Aunque se puede usar un bloque script para inyectar sintaxis de Pipeline Scriptado, el uso excesivo puede socavar los beneficios de la sintaxis Declarativa y hacer que el pipeline sea más difícil de leer.

Cuándo Usar Pipelines Declarativos

Los Pipelines Declarativos son la opción recomendada para la mayoría de los escenarios comunes de CI/CD. Son ideales para:

Equipos nuevos en Jenkins o Pipeline as Code.
Proyectos con procesos de construcción, prueba e implementación sencillos o moderadamente complejos.
Asegurar consistencia y mantenibilidad en muchos pipelines.
Aprovechar las características integradas de Jenkins para patrones comunes como ejecución paralela, etapas condicionales y notificaciones.

Pipelines Scriptados

El Pipeline Scriptado, construido directamente sobre el lenguaje de programación Groovy, fue la sintaxis original para Jenkins Pipeline as Code. Ofrece máxima flexibilidad y potencia, permitiendo a los desarrolladores implementar flujos de automatización altamente personalizados y dinámicos.

Características y Sintaxis

Los Pipelines Scriptados se ejecutan secuencialmente de arriba a abajo, muy similar a un script Groovy tradicional. Utilizan la sintaxis completa de Groovy y aprovechan el DSL (Lenguaje Específico del Dominio) de Jenkins Pipeline a través de métodos como node, stage, checkout, sh, git, etc. Esto proporciona acceso directo a la API de Jenkins y todo el poder del lenguaje Groovy.

Aquí hay una estructura básica de un Pipeline Scriptado:

node('my-agent-label') {
    stage('Prepare') {
        echo 'Preparando el espacio de trabajo...'
        checkout scm
    }

    stage('Build') {
        echo 'Construyendo la aplicación...'
        try {
            sh 'mvn clean install'
        } catch (err) {
            echo "Construcción fallida: ${err}"
            // Manejo de errores personalizado
            currentBuild.result = 'FAILURE'
            throw err
        }
    }

    stage('Test') {
        echo 'Ejecutando pruebas...'
        // Determinar dinámicamente los conjuntos de pruebas
        def testSuites = sh(script: 'find tests -name "*.test"', returnStdout: true).trim().split('\n')
        if (testSuites.isEmpty()) {
            echo 'No se encontraron pruebas.'
        } else {
            for (suite in testSuites) {
                echo "Ejecutando conjunto de pruebas: ${suite}"
                sh "./run-test.sh ${suite}"
            }
        }
    }

    stage('Deploy') {
        // Lógica condicional compleja
        if (env.BRANCH_NAME == 'main' && currentBuild.currentResult == 'SUCCESS') {
            echo 'Implementando en producción...'
            sh './deploy-prod.sh'
        } else if (env.BRANCH_NAME == 'develop') {
            echo 'Implementando en staging...'
            sh './deploy-staging.sh'
        } else {
            echo 'No hay implementación para esta rama.'
        }
    }

    // Las acciones posteriores a la construcción se pueden implementar con bloques try-finally o lógica personalizada
    // Por ejemplo, enviar notificaciones
    if (currentBuild.result == 'SUCCESS') {
        echo '¡Pipeline completado exitosamente!'
        // notifySuccess()
    } else {
        echo 'Pipeline fallido.'
        // notifyFailure()
    }
}

Ventajas de los Pipelines Scriptados

Máxima Flexibilidad: Ofrece todo el poder de Groovy, permitiendo lógica altamente compleja y dinámica, bucles personalizados, manejo de errores y manipulación de datos.
Acceso Directo a la API de Jenkins: Proporciona más espacio para el uso de las API de Jenkins y Groovy, aunque algunas operaciones aún dependen de plugins, permisos y el sandbox de Seguridad de Scripts.
Comportamiento Dinámico: Ideal para flujos de trabajo que requieren asignación dinámica de agentes, ejecución paralela basada en condiciones de tiempo de ejecución o gestión avanzada de recursos.
Extensibilidad: Excelente para crear Bibliotecas Compartidas sofisticadas que encapsulan lógica compleja y reutilizable para Pipelines Declarativos.

Limitaciones de los Pipelines Scriptados

Curva de Aprendizaje más Pronunciada: Requiere un sólido entendimiento de Groovy, lo que puede ser una barrera para equipos no familiarizados con el lenguaje.
Menos Opinado: Sin una estructura estricta, los pipelines pueden volverse inconsistentes y más difíciles de leer o mantener en diferentes proyectos o desarrolladores.
Propenso a Errores: La flexibilidad de Groovy significa más oportunidades para errores de codificación y menos validación integrada en comparación con Declarativo.
Desafíos de Legibilidad: Los Pipelines Scriptados complejos pueden volverse rápidamente difíciles de analizar y entender, dificultando la colaboración y la resolución de problemas.
Menos Sintaxis Específica de Pipeline: Muchos patrones comunes de CI/CD (como acciones post o condiciones when) deben implementarse manualmente usando construcciones de Groovy (por ejemplo, try-catch-finally, sentencias if).

Declarativo vs. Scriptado: Una Comparación Lado a Lado

Para ayudar a resumir las diferencias, aquí hay una tabla comparativa:

Característica	Pipeline Declarativo	Pipeline Scriptado
Estructura de Sintaxis	Opinada, bloques predefinidos de nivel superior.	Flexible, basada en Groovy, ejecución secuencial.
Curva de Aprendizaje	Más fácil para principiantes, menos conocimiento de Groovy necesario.	Más pronunciada, requiere experiencia en Groovy.
Legibilidad	Alta debido a bloques estructurados y sintaxis clara.	Puede ser baja para scripts complejos, depende del estilo del desarrollador.
Flexibilidad	Limitada a estructuras predefinidas; bloques `script` para Groovy.	Ilimitada, todo el poder de Groovy.
Características Integradas	Conjunto rico para patrones comunes de CI/CD (`post`, `when`, `parallel`).	Requiere implementación manual usando construcciones de Groovy.
Manejo de Errores	Bloques `post` para acciones globales o específicas de etapa.	Bloques manuales `try-catch-finally`.
Extensibilidad	Aprovecha Bibliotecas Compartidas para lógica Groovy compleja.	Escribe directamente lógica Groovy compleja. A menudo crea Bibliotecas Compartidas.
Control de Agente	`agent` global o `agent` a nivel de etapa.	Bloques `node`, puede definir agentes en cualquier lugar.
Casos de Uso	Flujos de trabajo CI/CD estándar, complejidad simple a moderada.	Flujos de trabajo altamente dinámicos, complejos y personalizados; desarrollo de Bibliotecas Compartidas.
Sensación JSON/YAML	Más similar a lenguajes de configuración.	Lenguaje de programación puro.

Eligiendo la Sintaxis Correcta

Al decidir entre Pipelines Declarativos y Scriptados, considera los siguientes factores:

Experiencia del Equipo en Groovy: Si tu equipo carece de sólidas habilidades en Groovy, Declarativo tendrá una curva de aprendizaje mucho más superficial y promoverá una adopción más rápida.
Complejidad del Flujo de Trabajo: Para la mayoría de los flujos de trabajo CI/CD estándar (construir, probar, implementar), Declarativo es perfectamente adecuado y a menudo superior debido a su legibilidad y características integradas. Para tareas altamente dinámicas, condicionales o intensivas en recursos personalizados, Scriptado podría ser necesario.
Mantenibilidad y Legibilidad: Los pipelines Declarativos son generalmente más fáciles de leer y mantener, especialmente para grandes organizaciones con muchos pipelines y desarrolladores. Esta consistencia reduce la carga cognitiva.
Ecosistema de Pipeline Existente: Si tienes Pipelines Scriptados existentes o un conjunto robusto de Bibliotecas Compartidas construidas con sintaxis Scriptada, podrías mantenerte con ella por consistencia, o migrar progresivamente a Declarativo donde sea apropiado.
Crecimiento Futuro: Los pipelines Declarativos suelen ser suficientes y se pueden extender con lógica personalizada a través de Bibliotecas Compartidas, que a su vez suelen estar escritas en Groovy Scriptado. Este suele ser el mejor enfoque híbrido.

Mejores Prácticas para la Toma de Decisiones

Comienza con Declarativo: Para nuevos pipelines, opta por Declarativo por defecto. Cubre la gran mayoría de los casos de uso de CI/CD y promueve la consistencia y legibilidad.
Aprovecha las Bibliotecas Compartidas: Cuando encuentres lógica repetitiva o compleja en tus Pipelines Declarativos, abstrae esa lógica en una Biblioteca Compartida. Las Bibliotecas Compartidas se escriben principalmente en Groovy Scriptado, lo que te permite combinar lo mejor de ambos mundos: la estructura de Declarativo y la flexibilidad de Scriptado.
Evita Sobrescribir Declarativo: Aunque Declarativo permite bloques script, trata de mantenerlos al mínimo. Si un bloque script se vuelve demasiado grande o complejo, es un fuerte indicador de que la lógica debería moverse a una función de Biblioteca Compartida.
Considera la Migración: Si tienes Pipelines Scriptados heredados que se están volviendo difíciles de mantener, considera refactorizarlos a sintaxis Declarativa, moviendo las partes complejas a Bibliotecas Compartidas.

Conclusión

Para nuevos Jenkinsfiles, elige Declarativo a menos que tengas una razón concreta para no hacerlo. Mueve el Groovy repetido o complejo a Bibliotecas Compartidas, y reserva los pipelines completamente Scriptados para flujos de trabajo que no encajen limpiamente en las etapas, condiciones y pasos de Declarativo.