Dichiarativo vs. Scripted: Scegliere la Sintassi della Pipeline Jenkins

Jenkins Pipeline ti offre due modi per scrivere un Jenkinsfile: Dichiarativo e Scripted. Entrambi possono compilare, testare e distribuire la tua applicazione, ma ti portano verso diversi compromessi in termini di leggibilità, validazione e flessibilità di Groovy.

Se il tuo team sta scegliendo una sintassi per una nuova pipeline, inizia dal flusso di lavoro che dovrai mantenere tra sei mesi. Il Dichiarativo è solitamente più facile da leggere e revisionare. Lo Scripted ti offre un controllo più diretto di Groovy quando la pipeline necessita veramente di un comportamento dinamico.

Comprendere le Pipeline Jenkins

Prima di addentrarci nelle sintassi, ricordiamo brevemente cos'è una Pipeline Jenkins. Una Pipeline è un insieme di plugin che supporta l'implementazione e l'integrazione di pipeline di consegna continua in Jenkins. È essenzialmente una sequenza di passaggi automatizzati che definiscono l'intero processo di consegna del software, dal commit del codice alla distribuzione. Questi passaggi sono definiti in un Jenkinsfile, tipicamente scritto in Groovy, e offrono un modo potente per gestire scenari complessi di compilazione, test e distribuzione.

Jenkins Pipeline as Code offre diversi vantaggi chiave:

Controllo di Versione: Il Jenkinsfile è memorizzato nel controllo del codice sorgente, proprio come il codice dell'applicazione, consentendo versionamento, audit e collaborazione.
Ripetibilità: Assicura un'esecuzione coerente del processo di consegna in diversi ambienti ed esecuzioni.
Visibilità: Fornisce una visione chiara e comprensibile dell'intero processo di consegna.
Durabilità: Le pipeline possono sopravvivere ai riavvii del master Jenkins.
Estendibilità: Attraverso librerie condivise, la logica complessa può essere astratta e riutilizzata.

Pipeline Dichiarative

La Pipeline Dichiarativa è la sintassi più recente e opinionata progettata per rendere più facile scrivere e comprendere le pipeline. Fornisce un approccio strutturato con blocchi predefiniti, che aiuta i team a mantenere i Jenkinsfile coerenti.

Caratteristiche e Sintassi

Le Pipeline Dichiarative impongono una struttura specifica definita da blocchi di alto livello come pipeline, agent, stages, steps, post, environment, parameters, options, triggers, tools, input e when. Questa struttura semplifica la definizione della pipeline fornendo confini chiari per diverse parti del flusso di lavoro.

Ecco una struttura di base di una Pipeline Dichiarativa:

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

    stages {
        stage('Build') {
            steps {
                echo 'Compilazione dell\'applicazione...'
                sh 'mvn clean install'
            }
        }
        stage('Test') {
            steps {
                echo 'Esecuzione dei test...'
                sh 'mvn test'
            }
        }
        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                echo 'Distribuzione in produzione...'
                script {
                    // La logica simile a Scripted può essere inserita qui se assolutamente necessario
                    // Ad esempio, chiamare una funzione di libreria condivisa
                    // mySharedLibrary.deployApplication()
                }
            }
        }
    }

    post {
        always {
            echo 'Pipeline terminata.'
        }
        success {
            echo 'Pipeline completata con successo!'
        }
        failure {
            echo 'Pipeline fallita.'
        }
    }
}

Vantaggi delle Pipeline Dichiarative

Semplicità e Leggibilità: La struttura predefinita rende le pipeline facili da leggere e comprendere, anche per i non esperti. Sembra più un file di configurazione.
Approccio Strutturato: Impone best practice e coerenza tra le pipeline, riducendo la curva di apprendimento e il potenziale di errori.
Funzionalità Integrate: Offre un ricco insieme di funzionalità integrate per modelli CI/CD comuni, come l'esecuzione condizionale (when), azioni post-build (post), esecuzione parallela di stage e varie opzioni per gestire il flusso della pipeline.
Più Facile da Imparare: Gli sviluppatori senza una conoscenza approfondita di Groovy possono iniziare rapidamente grazie alla sua sintassi opinionata.
Validazione: Jenkins può validare più della struttura prima dell'esecuzione perché il Dichiarativo ha regole più rigide.

Limitazioni delle Pipeline Dichiarative

Meno Flessibili: La struttura rigida può essere restrittiva per flussi di lavoro altamente complessi o dinamici che richiedono logica Groovy personalizzata al di fuori dei blocchi predefiniti.
Accesso Diretto Limitato a Groovy: Sebbene un blocco script possa essere utilizzato per iniettare la sintassi Scripted Pipeline, un uso eccessivo può minare i vantaggi della sintassi Dichiarativa e rendere la pipeline più difficile da leggere.

Quando Utilizzare le Pipeline Dichiarative

Le Pipeline Dichiarative sono la scelta consigliata per la maggior parte degli scenari CI/CD comuni. Sono ideali per:

Team nuovi a Jenkins o Pipeline as Code.
Progetti con processi di compilazione, test e distribuzione semplici o moderatamente complessi.
Garantire coerenza e manutenibilità tra molte pipeline.
Sfruttare le funzionalità integrate di Jenkins per modelli comuni come esecuzione parallela, stage condizionali e notifiche.

Pipeline Scripted

La Pipeline Scripted, costruita direttamente sul linguaggio di programmazione Groovy, era la sintassi originale per Jenkins Pipeline as Code. Offre la massima flessibilità e potenza, consentendo agli sviluppatori di implementare flussi di automazione altamente personalizzati e dinamici.

Caratteristiche e Sintassi

Le Pipeline Scripted vengono eseguite sequenzialmente dall'alto verso il basso, proprio come uno script Groovy tradizionale. Usano la sintassi completa di Groovy e sfruttano il DSL (Domain Specific Language) di Jenkins Pipeline attraverso metodi come node, stage, checkout, sh, git, ecc. Questo fornisce accesso diretto all'API di Jenkins e alla piena potenza del linguaggio Groovy.

Ecco una struttura di base di una Pipeline Scripted:

node('my-agent-label') {
    stage('Prepare') {
        echo 'Preparazione del workspace...'
        checkout scm
    }

    stage('Build') {
        echo 'Compilazione dell\'applicazione...'
        try {
            sh 'mvn clean install'
        } catch (err) {
            echo "Compilazione fallita: ${err}"
            // Gestione errori personalizzata
            currentBuild.result = 'FAILURE'
            throw err
        }
    }

    stage('Test') {
        echo 'Esecuzione dei test...'
        // Determinare dinamicamente le suite di test
        def testSuites = sh(script: 'find tests -name "*.test"', returnStdout: true).trim().split('\n')
        if (testSuites.isEmpty()) {
            echo 'Nessun test trovato.'
        } else {
            for (suite in testSuites) {
                echo "Esecuzione della suite di test: ${suite}"
                sh "./run-test.sh ${suite}"
            }
        }
    }

    stage('Deploy') {
        // Logica condizionale complessa
        if (env.BRANCH_NAME == 'main' && currentBuild.currentResult == 'SUCCESS') {
            echo 'Distribuzione in produzione...'
            sh './deploy-prod.sh'
        } else if (env.BRANCH_NAME == 'develop') {
            echo 'Distribuzione in staging...'
            sh './deploy-staging.sh'
        } else {
            echo 'Nessuna distribuzione per questo branch.'
        }
    }

    // Le azioni post-build possono essere implementate con blocchi try-finally o logica personalizzata
    // Ad esempio, invio di notifiche
    if (currentBuild.result == 'SUCCESS') {
        echo 'Pipeline completata con successo!'
        // notifySuccess()
    } else {
        echo 'Pipeline fallita.'
        // notifyFailure()
    }
}

Vantaggi delle Pipeline Scripted

Massima Flessibilità: Offre tutta la potenza di Groovy, consentendo logiche altamente complesse e dinamiche, cicli personalizzati, gestione degli errori e manipolazione dei dati.
Accesso Diretto all'API Jenkins: Fornisce più spazio per l'uso delle API Jenkins e Groovy, sebbene alcune operazioni dipendano ancora da plugin, permessi e dal sandbox di Script Security.
Comportamento Dinamico: Ideale per flussi di lavoro che richiedono allocazione dinamica degli agenti, esecuzione parallela basata su condizioni di runtime o gestione avanzata delle risorse.
Estendibilità: Eccellente per creare librerie condivise sofisticate che incapsulano logiche complesse e riutilizzabili per le Pipeline Dichiarative.

Limitazioni delle Pipeline Scripted

Curva di Apprendimento più Ripida: Richiede una solida conoscenza di Groovy, che può essere un ostacolo per i team non familiari con il linguaggio.
Meno Opinionata: Senza una struttura rigida, le pipeline possono diventare incoerenti e più difficili da leggere o mantenere tra diversi progetti o sviluppatori.
Soggetta a Errori: La flessibilità di Groovy significa più opportunità per errori di codifica e meno validazione integrata rispetto al Dichiarativo.
Sfide di Leggibilità: Le Pipeline Scripted complesse possono rapidamente diventare difficili da analizzare e comprendere, ostacolando la collaborazione e la risoluzione dei problemi.
Meno Sintassi Specifica per Pipeline: Molti modelli CI/CD comuni (come azioni post o condizioni when) devono essere implementati manualmente utilizzando costrutti Groovy (ad esempio, try-catch-finally, istruzioni if).

Dichiarativo vs. Scripted: Un Confronto Affiancato

Per aiutare a riassumere le differenze, ecco una tabella comparativa:

Caratteristica	Pipeline Dichiarativa	Pipeline Scripted
Struttura della Sintassi	Opinionata, blocchi di alto livello predefiniti.	Flessibile, basata su Groovy, esecuzione sequenziale.
Curva di Apprendimento	Più facile per i principianti, meno conoscenza di Groovy necessaria.	Più ripida, richiede competenze Groovy.
Leggibilità	Alta grazie a blocchi strutturati e sintassi chiara.	Può essere bassa per script complessi, dipende dallo stile dello sviluppatore.
Flessibilità	Limitata a strutture predefinite; blocchi `script` per Groovy.	Illimitata, piena potenza di Groovy.
Funzionalità Integrate	Ricco insieme per modelli CI/CD comuni (`post`, `when`, `parallel`).	Richiede implementazione manuale usando costrutti Groovy.
Gestione degli Errori	Blocchi `post` per azioni globali o specifiche dello stage.	Blocchi manuali `try-catch-finally`.
Estendibilità	Sfrutta le librerie condivise per logica Groovy complessa.	Scrive direttamente logica Groovy complessa. Spesso crea librerie condivise.
Controllo dell'Agente	`agent` globale o `agent` a livello di stage.	Blocchi `node`, può definire agenti ovunque.
Casi d'Uso	Flussi di lavoro CI/CD standard, complessità semplice o moderata.	Flussi di lavoro altamente dinamici, complessi e personalizzati; sviluppo di librerie condivise.
Sensazione JSON/YAML	Più simile ai linguaggi di configurazione.	Linguaggio di programmazione puro.

Scegliere la Sintassi Giusta

Quando decidi tra Pipeline Dichiarative e Scripted, considera i seguenti fattori:

Competenze Groovy del Team: Se il tuo team manca di forti competenze Groovy, il Dichiarativo avrà una curva di apprendimento molto più bassa e promuoverà un'adozione più rapida.
Complessità del Flusso di Lavoro: Per la maggior parte dei flussi di lavoro CI/CD standard (compilazione, test, distribuzione), il Dichiarativo è perfettamente adeguato e spesso superiore grazie alla sua leggibilità e funzionalità integrate. Per attività altamente dinamiche, condizionali o personalizzate che richiedono molte risorse, lo Scripted potrebbe essere necessario.
Manutenibilità e Leggibilità: Le pipeline Dichiarative sono generalmente più facili da leggere e mantenere, specialmente per grandi organizzazioni con molte pipeline e sviluppatori. Questa coerenza riduce il carico cognitivo.
Ecosistema di Pipeline Esistente: Se hai pipeline Scripted esistenti o un robusto insieme di librerie condivise costruite con sintassi Scripted, potresti mantenerle per coerenza, o migrare progressivamente al Dichiarativo dove appropriato.
Crescita Futura: Le pipeline Dichiarative sono solitamente sufficienti e possono essere estese con logica personalizzata attraverso librerie condivise, che a loro volta sono tipicamente scritte in Groovy Scripted. Questo è spesso il miglior approccio ibrido.

Best Practice per il Processo Decisionale

Inizia con il Dichiarativo: Per le nuove pipeline, scegli il Dichiarativo per impostazione predefinita. Copre la stragrande maggioranza dei casi d'uso CI/CD e promuove coerenza e leggibilità.
Sfrutta le Librerie Condivise: Quando incontri logiche ripetitive o complesse nelle tue Pipeline Dichiarative, astrai quella logica in una libreria condivisa. Le librerie condivise sono principalmente scritte in Groovy Scripted, permettendoti di combinare il meglio di entrambi i mondi: la struttura del Dichiarativo e la flessibilità dello Scripted.
Evita di Eccessiva Scripting nel Dichiarativo: Sebbene il Dichiarativo permetta blocchi script, cerca di mantenerli minimi. Se un blocco script diventa troppo grande o complesso, è un forte indicatore che la logica dovrebbe essere spostata in una funzione di libreria condivisa.
Considera la Migrazione: Se hai pipeline Scripted legacy che stanno diventando difficili da mantenere, considera di rifattorizzarle in sintassi Dichiarativa, spostando le parti complesse in librerie condivise.

Conclusione

Per i nuovi Jenkinsfile, scegli il Dichiarativo a meno che tu non abbia un motivo concreto per non farlo. Sposta la logica Groovy ripetitiva o complessa in librerie condivise e riserva le pipeline completamente Scripted per flussi di lavoro che non possono adattarsi in modo pulito agli stage, condizioni e passaggi Dichiarativi.