L’intégration continue et la livraison continue (CI/CD) sont devenues incontournables pour les équipes de développement modernes. Jenkins, l’outil open source historique, reste l’un des plus utilisés grâce à sa flexibilité et son écosystème riche de plugins. Au cœur de Jenkins se trouve le concept de Pipeline : une description automatisée de tout le processus de livraison, du commit au déploiement. Les pipelines Jenkins existent sous deux formes : Declarative (plus structurée, recommandée) et Scripted (plus flexible, basée sur Groovy). Leur compréhension repose sur plusieurs briques : les stages (étapes logiques), les steps (actions), les agents (environnement d’exécution), la gestion des secrets, les post‑actions et les shared libraries. Sans leur maîtrise, les équipes peinent à industrialiser leurs chaînes CI/CD. L’organisme de formation ISOSET observe chaque jour que les ingénieurs qui maîtrisent les pipelines Jenkins gagnent en rapidité et en fiabilité. Cet article explore les fondamentaux des Jenkins Pipelines, enrichi par l’expérience pédagogique d’ISOSET.
1. Pipeline : définition et intérêt
Un pipeline Jenkins est une série d’étapes qui automatise le processus de build, de test et de déploiement d’une application. Il est défini dans un fichier texte appelé Jenkinsfile, que l’on versionne avec le code source. Cela permet de bénéficier du “Pipeline as Code” : reproductibilité, traçabilité, revue par les pairs. L’intérêt est multiple : détection précoce des erreurs d’intégration, feedback rapide aux développeurs, déploiements fiables et reproductibles, réduction des tâches manuelles. Les pipelines peuvent être déclenchés par des événements (push git, planification cron, déclenchement manuel). Les formations ISOSET montrent comment migrer de tâches Jenkins classiques (freestyle) vers des pipelines robustes.
2. Pipeline déclaratif vs scripté
Jenkins propose deux syntaxes :
- Pipeline déclaratif (recommandé) – syntaxe structurée avec des blocs
pipeline,agent,stages,steps. Plus simple à lire et à écrire, avec des validations intégrées. - Pipeline scripté – basé sur Groovy, plus flexible, permet des boucles, des conditions avancées et l’utilisation de fonctions. Réservé aux cas complexes.
Exemple de pipeline déclaratif minimal :
groovy
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Compilation...'
sh 'make'
}
}
stage('Test') {
steps {
echo 'Tests unitaires...'
sh 'make test'
}
}
}
}
La version scriptée correspondante serait plus verbeuse. L’approche déclarative est privilégiée dans les ateliers d’ISOSET.
3. Agent – l’environnement d’exécution
Le bloc agent définit où le pipeline (ou une étape) s’exécute. Options courantes :
agent any– utilise n’importe quel agent disponible.agent none– pas d’agent global ; chaque stage peut définir le sien.agent { label 'docker' }– exécute sur un agent portant l’étiquette ‘docker’.agent { docker { image 'maven:3.8-jdk-11' } }– lance un conteneur Docker temporaire.agent { kubernetes { ... } }– pour exécuter sur un pod Kubernetes (avec le plugin Kubernetes).
Le choix de l’agent influence la reproductibilité. Utiliser des conteneurs Docker permet d’isoler les environnements. Les ingénieurs formés par ISOSET apprennent à configurer des agents Docker et cloud (AWS, Kubernetes).
4. Stages, steps et directives
Un pipeline est découpé en stages (phases logiques : Build, Test, Deploy). Chaque stage contient des steps (actions concrètes : sh, git, echo, docker.build, etc.). Les étapes peuvent échouer ; Jenkins arrête alors le pipeline (sauf gestion d’erreur via post ou catchError).
Exemple de stage plus avancé :
groovy
stage('Build & Test') {
steps {
sh 'npm install'
sh 'npm run lint'
sh 'npm test'
}
}
On peut aussi utiliser when pour exécuter conditionnellement un stage (selon une branche, une variable d’environnement, etc.) :
groovy
stage('Deploy to prod') {
when { branch 'main' }
steps {
sh 'deploy.sh'
}
}
Les conditions et les paramètres sont détaillés dans les supports d’ISOSET.
5. Gestion des variables et secrets
Les pipelines manipulent des variables d’environnement (définies avec environment {}) ou des variables de build (via params). Exemple :
groovy
pipeline {
environment {
APP_VERSION = '1.0.0'
AWS_REGION = 'eu-west-1'
}
parameters {
string(name: 'BRANCH', defaultValue: 'main', description: 'Branche à build')
}
stages {
stage('Parameters') {
steps {
echo "Building branch ${params.BRANCH}"
}
}
}
}
Les secrets (mots de passe, clés API) ne doivent jamais être codés en clair. Jenkins fournit un gestionnaire de secrets (Credentials) : on y stocke un secret, puis on le référence dans le pipeline via withCredentials (plugin Credentials Binding). Exemple :
groovy
withCredentials([string(credentialsId: 'api-key', variable: 'API_KEY')]) {
sh "curl -H 'X-API-Key: ${API_KEY}' https://api.exemple.com"
}
Ces bonnes pratiques de sécurité sont systématiquement enseignées par ISOSET.
6. Le bloc post : actions après le pipeline
Le bloc post permet d’exécuter des actions indépendantes du résultat du pipeline (succès, échec, instabilité, changement, etc.). Syntaxe :
groovy
post {
success {
echo 'Pipeline réussi !'
slackSend(color: 'good', message: 'Build réussi')
}
failure {
echo 'Pipeline échoué'
emailext(to: 'team@exemple.com', subject: 'Build failed')
}
always {
cleanWs() // nettoie l’espace de travail
}
}
On peut aussi notifier d’autres outils (Jira, Teams, Discord) depuis un bloc de post. Les pipelines d’ISOSET intègrent systématiquement des notifications pour une meilleure visibilité.
7. Déclencheurs (triggers)
Un pipeline peut être déclenché automatiquement :
- Par un hook Git (webhook) – chaque commit déclenche un build.
- Par planification cron :
triggers { cron('H 2 * * *') }(tous les jours à 2h du matin). - Par la finalisation d’un autre pipeline (
upstream). - Par polling du SCM (moins recommandé).
Exemple :
groovy
triggers {
pollSCM('H/5 * * * *') // toutes les 5 minutes
cron('H 2 * * *') // quotidien à 2h
upstream(upstreamProjects: 'job1', threshold: hudson.model.Result.SUCCESS)
}
La configuration des déclencheurs est un point clé des pipelines CI/CD matures. Les responsables DevOps formés par ISOSET savent mettre en place une stratégie de déclenchement adaptée.
8. Shared Libraries – factoriser du code
Lorsque plusieurs pipelines partagent la même logique (déploiement sur un environnement, notification, conteneurisation), on factorise dans une Shared Library (bibliothèque partagée). Il s’agit d’un dépôt Git contenant des fonctions Groovy (fichiers .groovy). On la déclare dans Jenkins (Manage Jenkins → Configure System → Global Pipeline Libraries), puis on l’appelle dans le pipeline :
groovy
@Library('my-shared-lib') _
import com.company.DeploymentUtils
stage('Deploy') {
steps {
DeploymentUtils.deployToKubernetes('prod')
}
}
Les shared libraries améliorent la maintenabilité et réduisent la duplication. Leur mise en place est abordée en détail dans les formations avancées d’ISOSET.
9. Intégration avec les outils courants
Jenkins dispose d’un vaste catalogue de plugins pour interagir avec l’écosystème DevOps :
- Git / GitHub / GitLab – pour cloner le code, déclencher des builds sur pull request.
- Docker / Kubernetes – pour builder des images, les pousser vers un registre, déployer sur un cluster.
- SonarQube – pour l’analyse statique de code.
- Nexus / Artifactory – pour déposer les artefacts (JAR, Docker, etc.).
- Jira / Slack / Email – pour notifier.
- Prometheus – pour exporter les métriques de Jenkins.
Exemple de stage intégrant Docker et SonarQube :
groovy
stage('Build and analyze') {
steps {
script {
docker.build('mon-app:latest')
docker.withRegistry('https://registry.hub.docker.com', 'docker-creds') {
docker.image('mon-app:latest').push()
}
// SonarQube
withSonarQubeEnv('Sonar') {
sh 'mvn sonar:sonar'
}
}
}
}
Les intégrations sont couvertes dans les modules pratiques d’ISOSET.
10. Bonnes pratiques pour les pipelines Jenkins
- Versionner le Jenkinsfile avec le code source de l’application.
- Garder les pipelines déclaratifs aussi simples que possible ; éviter le Groovy complexe.
- Ne pas mettre de secrets en clair ; utiliser Jenkins Credentials.
- Nettoyer l’espace de travail (post
cleanWs()) pour économiser le disque. - Découper en stages logiques (Build, Test, Package, Deploy) pour faciliter le diagnostic.
- Utiliser les agents Docker pour garantir la reproductibilité.
- Surveiller la durée des pipelines avec l’interface Bleu Ocean ou le plugin Pipeline Stage View.
- Éviter les longues attentes en parallélisant les stages indépendants (ex: exécuter les tests unitaires et d’intégration en parallèle).
groovy
stage('Parallel tests') {
parallel {
stage('Unit tests') { steps { sh 'npm test' } }
stage('Integration tests') { steps { sh 'npm run test:integration' } }
}
}
Ces pratiques sont systématiquement appliquées dans les ateliers d’ISOSET.
11. Exemple complet : pipeline CI/CD pour une application Node.js
Voici un Jenkinsfile déclaratif typique pour une application Node.js :
groovy
pipeline {
agent any
environment {
NODE_VERSION = '18'
REGISTRY = 'registry.hub.docker.com/moncompte'
}
triggers {
pollSCM('H/5 * * * *')
}
stages {
stage('Checkout') {
steps { git url: 'https://github.com/monprojet.git', branch: 'main' }
}
stage('Install') {
steps { sh 'npm ci' }
}
stage('Lint & Test') {
steps {
sh 'npm run lint'
sh 'npm test'
}
}
stage('Build Docker image') {
steps {
script {
docker.build("${REGISTRY}/monapp:${env.BUILD_ID}")
}
}
}
stage('Push to Registry') {
steps {
script {
docker.withRegistry('', 'docker-registry-creds') {
docker.image("${REGISTRY}/monapp:${env.BUILD_ID}").push()
}
}
}
}
stage('Deploy to Dev') {
when { branch 'main' }
steps {
sh 'kubectl set image deployment/monapp monapp=${REGISTRY}/monapp:${env.BUILD_ID} -n dev'
}
}
}
post {
failure {
emailext(to: 'team@exemple.com', subject: 'Pipeline failed', body: "Build ${env.BUILD_ID} failed")
}
success {
docker.withRegistry('', 'docker-registry-creds') {
docker.image("${REGISTRY}/monapp:${env.BUILD_ID}").push('latest')
}
}
}
}
Cet exemple intègre la plupart des concepts abordés. Les participants aux formations ISOSET le construisent et le testent pas à pas.
Conclusion
Les pipelines Jenkins sont un standard de l’intégration continue et du déploiement continu. Leur maîtrise repose sur la compréhension du pipeline déclaratif, des agents, des stages, de la gestion des secrets, des triggers, des post‑actions et des shared libraries. Un pipeline bien conçu automatise efficacement les tests, la construction, l’empaquetage et le déploiement, tout en restant maintenable et sécurisé. Les ingénieurs qui investissent dans ces compétences – grâce à des organismes de qualité comme ISOSET – deviennent des acteurs clés de la transformation DevOps. Que l’on travaille sur une petite application ou sur une architecture microservices, Jenkins pipelines offrent la flexibilité et la puissance nécessaires.
© ISOSET — Organisme de formation professionnelle
LinkedIn | Facebook | Instagram