Sintassi delle Pipeline Jenkins: Una Guida Completa per Principianti
Demistifica la sintassi delle pipeline Jenkins con questa guida completa per principianti. Impara gli elementi essenziali delle pipeline Declarative e Scripted, inclusi agenti, stage, step, post-azioni, ambienti, parametri e le migliori pratiche. Mettiti in grado di costruire flussi di lavoro CI/CD robusti in modo efficace con esempi pratici e consigli attuabili.
Sintassi di Jenkins Pipeline: Una Guida Completa per Principianti
La sintassi di Jenkins Pipeline ti permette di descrivere il tuo processo di build, test e deploy in un Jenkinsfile che vive con il tuo codice. Questo è importante perché le modifiche alla tua pipeline possono essere revisionate, versionate e ripristinate come il codice dell'applicazione.
Se sei nuovo alle pipeline di Jenkins, inizia con la sintassi della Pipeline Dichiarativa. È strutturata, leggibile e copre la maggior parte dei flussi di lavoro CI/CD senza richiedere molta conoscenza di Groovy.
Pipeline Dichiarativa vs. Scriptata
Jenkins supporta due stili di pipeline.
La Pipeline Dichiarativa utilizza una struttura rigida pipeline { ... }. È l'impostazione predefinita migliore per la maggior parte dei team perché Jenkins può validare la forma del file e mostrare gli stage in modo pulito nell'interfaccia utente.
La Pipeline Scriptata utilizza Groovy all'interno di blocchi node { ... }. Ti dà più controllo, ma è più facile creare pipeline difficili da mantenere se il tuo team non ha familiarità con Groovy.
Usa prima la Dichiarativa. Ricorri alla Scriptata solo quando hai bisogno di logiche che la Dichiarativa non può esprimere in modo pulito.
Una Pipeline Dichiarativa Minima
Un Jenkinsfile di base ha un agent, degli stage e degli step:
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building the application'
sh 'mvn clean package'
}
}
stage('Test') {
steps {
sh 'mvn test'
}
}
}
}
agent any dice a Jenkins di eseguire la pipeline su qualsiasi agent disponibile. Ogni stage appare separatamente nell'interfaccia utente di Jenkins. Il blocco steps contiene i comandi che Jenkins esegue.
Su agent Windows, usa bat invece di sh:
bat 'gradlew.bat test'
La Direttiva agent
La direttiva agent decide dove viene eseguita la pipeline o lo stage.
Esegui su qualsiasi agent disponibile:
agent any
Esegui su un agent con un'etichetta specifica:
agent { label 'linux && docker' }
Salta un agent globale e scegline uno per stage:
pipeline {
agent none
stages {
stage('Build') {
agent { label 'linux' }
steps {
sh './build.sh'
}
}
}
}
agent none è utile quando diversi stage necessitano di ambienti diversi, come Linux per le build e Windows per i test degli installer.
Stage e Step
Usa gli stage per suddividere la pipeline in un lavoro che uno sviluppatore possa capire a colpo d'occhio: checkout, build, test, package, deploy.
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Unit Tests') {
steps {
sh 'npm test'
}
}
}
Mantieni gli stage significativi. Uno stage chiamato Run con cinquanta comandi è difficile da debuggare. Una pipeline con venti piccoli stage è rumorosa. Punta a stage che corrispondano a punti di controllo reali del flusso di lavoro.
Variabili d'Ambiente
Usa environment per valori di cui diversi stage hanno bisogno:
pipeline {
agent any
environment {
APP_NAME = 'orders-api'
IMAGE = "registry.example.com/team/orders-api:${env.BUILD_NUMBER}"
}
stages {
stage('Build Image') {
steps {
sh 'docker build -t "$IMAGE" .'
}
}
}
}
Nelle stringhe Groovy, puoi leggere le variabili tramite env.APP_NAME. Negli step shell, Jenkins esporta le variabili d'ambiente in modo che $APP_NAME e $IMAGE funzionino all'interno della shell.
Non mettere segreti in environment. Usa le Credenziali di Jenkins con withCredentials.
Parametri
I parametri permettono a qualcuno di scegliere valori quando si avvia una build manualmente:
pipeline {
agent any
parameters {
string(name: 'BRANCH_NAME', defaultValue: 'main', description: 'Git branch to build')
booleanParam(name: 'RUN_TESTS', defaultValue: true, description: 'Run unit tests')
choice(name: 'DEPLOY_ENV', choices: ['dev', 'staging', 'prod'], description: 'Target environment')
}
stages {
stage('Show Inputs') {
steps {
echo "Branch: ${params.BRANCH_NAME}"
echo "Deploy target: ${params.DEPLOY_ENV}"
}
}
}
}
Usa i parametri per cose che dovrebbero variare tra le esecuzioni. Non usarli per bypassare la revisione per le modifiche alla produzione.
Stage Condizionali con when
La direttiva when controlla se uno stage viene eseguito:
stage('Deploy to Production') {
when {
branch 'main'
}
steps {
sh './deploy-prod.sh'
}
}
Puoi anche usare un'espressione:
stage('Test') {
when {
expression { return params.RUN_TESTS }
}
steps {
sh 'npm test'
}
}
Metti when sullo stage, non all'interno di steps.
Azioni Post-Esecuzione
I blocchi post vengono eseguiti dopo che uno stage o una pipeline termina. Sono utili per pubblicare report di test, archiviare evidenze di build e pulire.
pipeline {
agent any
stages {
stage('Test') {
steps {
sh 'mvn test'
}
post {
always {
junit 'target/surefire-reports/*.xml'
}
}
}
}
post {
failure {
echo 'Pipeline failed'
}
always {
cleanWs()
}
}
}
junit pubblica i risultati dei test anche quando i test falliscono. cleanWs() proviene dal plugin Workspace Cleanup, quindi installa quel plugin prima di usarlo.
Opzioni
Usa options per impostare il comportamento della pipeline:
pipeline {
agent any
options {
timestamps()
timeout(time: 30, unit: 'MINUTES')
disableConcurrentBuilds()
buildDiscarder(logRotator(numToKeepStr: '20'))
}
stages {
stage('Build') {
steps {
sh './build.sh'
}
}
}
}
Queste opzioni rendono i log più facili da leggere, fermano le build bloccate, prevengono esecuzioni sovrapposte dello stesso job e limitano la cronologia delle build vecchie.
Una Pipeline Pratica per Principianti
Questo esempio fa il checkout del codice, builda un progetto Java, pubblica i risultati dei test e archivia il JAR impacchettato:
pipeline {
agent { label 'linux' }
options {
timestamps()
timeout(time: 30, unit: 'MINUTES')
disableConcurrentBuilds()
}
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('Build') {
steps {
sh 'mvn clean package'
}
}
stage('Publish') {
steps {
junit 'target/surefire-reports/*.xml'
archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
}
}
}
}
Questo è un punto di partenza migliore rispetto a una pipeline di deploy gigante. Una volta che la build è affidabile, aggiungi la pubblicazione di immagini, scansioni di sicurezza o stage di deploy.
Basi della Pipeline Scriptata
Una Pipeline Scriptata semplice appare così:
node('linux') {
stage('Checkout') {
checkout scm
}
stage('Build') {
sh 'mvn clean package'
}
}
Non racchiudere un blocco pipeline {} Dichiarativo all'interno di una Pipeline Scriptata. Mantieni i due stili separati a meno che tu non abbia una ragione specifica e testata per mescolare piccole sezioni scriptate all'interno di blocchi script { ... } Dichiarativi.
Buone Abitudini per le Pipeline
Conserva il Jenkinsfile nel controllo versione. Mantieni i segreti nelle Credenziali di Jenkins. Dai agli stage nomi che corrispondano al lavoro che svolgono. Pubblica i report nei blocchi post in modo che i fallimenti lascino comunque evidenze utili. Aggiungi timeout prima che una build rimanga bloccata per tutta la notte.
La maggior parte dei problemi iniziali con le pipeline deriva da presupposti nascosti: uno strumento esiste su un agent ma non su un altro, un segreto è hardcodato, o un report viene pubblicato solo in caso di successo. Rendi questi presupposti espliciti nella pipeline, e Jenkins diventa molto più facile da fidarsi.