Jenkins CI/CD : Créer Votre Premier Pipeline

Les pipelines Jenkins CI/CD automatisent l’intégralité du processus de livraison logicielle — de la compilation du code et l’exécution des tests jusqu’au déploiement en production. En tant que serveur d’automatisation open source le plus utilisé au monde, Jenkins s’intègre avec pratiquement tous les outils de développement, fournisseurs cloud et systèmes de contrôle de version. Que vous déployiez une API Python, une application Node.js ou de l’infrastructure avec Terraform, les pipelines Jenkins définissent votre processus de livraison sous forme de code qui vit aux côtés de votre application. Ce guide vous accompagne dans l’installation de Jenkins, la rédaction de votre premier pipeline et la mise en place d’une automatisation prête pour la production.

Prérequis

• Un serveur avec au moins 2 Go de RAM et 10 Go d’espace disque (Ubuntu 22.04 ou version ultérieure recommandé)
• Java 17 ou version ultérieure installé (Jenkins requiert un JDK)
• Docker installé (optionnel mais recommandé pour les agents conteneurisés)
• Un dépôt Git avec du code applicatif à compiler
• Notions de base en YAML, Groovy et scripts shell

Installation de Jenkins

Via Docker (Recommandé)

# Créer un volume Docker pour les données persistantes
docker volume create jenkins-data

# Lancer Jenkins avec accès au socket Docker (pour les agents Docker)
docker run -d \
  --name jenkins \
  --restart unless-stopped \
  -p 8080:8080 \
  -p 50000:50000 \
  -v jenkins-data:/var/jenkins_home \
  -v /var/run/docker.sock:/var/run/docker.sock \
  jenkins/jenkins:lts

# Récupérer le mot de passe administrateur initial
docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

Via le Dépôt Officiel (Ubuntu/Debian)

# Ajouter la clé et la source du dépôt Jenkins
curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo tee \
  /usr/share/keyrings/jenkins-keyring.asc > /dev/null

echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian-stable binary/" | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null

# Installer Jenkins
sudo apt update
sudo apt install jenkins

# Jenkins démarre automatiquement — vérifier le statut
sudo systemctl status jenkins

# Récupérer le mot de passe administrateur initial
sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Ouvrez http://votre-serveur:8080 dans un navigateur, collez le mot de passe initial et suivez l’assistant de configuration. Installez les plugins suggérés — ils incluent Git, Pipeline et les intégrations les plus courantes.

Rédiger Votre Premier Jenkinsfile

Un Jenkinsfile définit votre pipeline sous forme de code. Il réside à la racine de votre dépôt Git et Jenkins le lit à chaque build.

Syntaxe Déclarative

// Jenkinsfile
pipeline {
    agent any

    environment {
        APP_NAME = 'my-web-app'
        DEPLOY_ENV = 'staging'
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Install Dependencies') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint') {
            steps {
                sh 'npm run lint'
            }
        }

        stage('Test') {
            steps {
                sh 'npm test'
            }
            post {
                always {
                    junit 'test-results/**/*.xml'
                }
            }
        }

        stage('Build') {
            steps {
                sh 'npm run build'
                archiveArtifacts artifacts: 'dist/**', fingerprint: true
            }
        }

        stage('Deploy to Staging') {
            when {
                branch 'main'
            }
            steps {
                sh './deploy.sh ${DEPLOY_ENV}'
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Pipeline Failed: ${APP_NAME} #${BUILD_NUMBER}",
                 body: "Check: ${BUILD_URL}"
        }
        success {
            echo 'Pipeline completed successfully!'
        }
    }
}

Pipeline avec Agents Docker

pipeline {
    agent none    // Pas d'agent global — chaque stage choisit le sien

    stages {
        stage('Build') {
            agent {
                docker {
                    image 'node:18-alpine'
                    args '-v $HOME/.npm:/root/.npm'    // Cache des paquets npm
                }
            }
            steps {
                sh 'npm ci && npm run build'
                stash includes: 'dist/**', name: 'build-output'
            }
        }

        stage('Test') {
            agent {
                docker { image 'node:18-alpine' }
            }
            steps {
                sh 'npm ci && npm test'
            }
        }

        stage('Docker Image') {
            agent any
            steps {
                unstash 'build-output'
                sh 'docker build -t myapp:${BUILD_NUMBER} .'
                sh 'docker push registry.example.com/myapp:${BUILD_NUMBER}'
            }
        }
    }
}

Chaque stage s’exécute dans un conteneur Docker vierge avec l’image spécifiée. Les commandes stash et unstash permettent de transmettre des artefacts de build entre des stages tournant sur des agents différents.

Gestion des Identifiants et des Secrets

Ne codez jamais les secrets en dur dans vos Jenkinsfiles. Utilisez le Jenkins Credentials Manager :

1. Accédez à Manage Jenkins > Credentials > System > Global credentials
2. Cliquez sur Add Credentials
3. Choisissez le type (Username/Password, SSH Key, Secret Text, etc.)
4. Donnez-lui un identifiant comme docker-registry-creds

Utilisez les identifiants dans votre pipeline :

stage('Deploy') {
    steps {
        withCredentials([
            usernamePassword(
                credentialsId: 'docker-registry-creds',
                usernameVariable: 'DOCKER_USER',
                passwordVariable: 'DOCKER_PASS'
            )
        ]) {
            sh 'docker login -u $DOCKER_USER -p $DOCKER_PASS registry.example.com'
            sh 'docker push registry.example.com/myapp:${BUILD_NUMBER}'
        }
    }
}

Les identifiants sont injectés comme variables d’environnement uniquement dans le bloc withCredentials et sont masqués dans les logs de build.

Comparaison Jenkins avec les Alternatives CI/CD

Fonctionnalité	Jenkins	GitHub Actions	GitLab CI	CircleCI
Auto-hébergé	Oui (principal)	Oui (runners)	Oui	Non
Hébergé dans le cloud	Non (communauté)	Oui	Oui	Oui
Configuration	Jenkinsfile (Groovy)	YAML	YAML	YAML
Écosystème de plugins	1800+ plugins	Marketplace d’actions	Fonctionnalités intégrées	Orbs
Support Docker	Via plugins	Natif	Natif	Natif
Tarification (auto-hébergé)	Gratuit (open source)	Gratuit (runners)	Gratuit (CE)	N/A
Courbe d’apprentissage	Élevée	Faible	Faible	Faible
Idéal pour	Workflows enterprise complexes	Projets natifs GitHub	Projets natifs GitLab	Équipes SaaS

Choisissez Jenkins lorsque vous avez besoin d’un contrôle total sur l’infrastructure de build, de workflows multi-branches complexes ou d’un environnement enterprise aux exigences de sécurité strictes. Choisissez GitHub Actions pour des projets déjà hébergés sur GitHub qui nécessitent un CI/CD simple sans gestion d’infrastructure.

Scénario Réel : Pipeline Multi-Branches

Votre équipe utilise des branches de fonctionnalité. Vous souhaitez que Jenkins compile et teste automatiquement chaque branche, déploie main en staging et ne déploie en production que les releases taguées.

pipeline {
    agent { docker { image 'node:18' } }

    stages {
        stage('Build & Test') {
            steps {
                sh 'npm ci && npm test && npm run build'
            }
        }

        stage('Deploy Staging') {
            when { branch 'main' }
            steps {
                sh './deploy.sh staging'
            }
        }

        stage('Deploy Production') {
            when { tag 'v*' }
            steps {
                input message: 'Deploy to production?', ok: 'Deploy'
                sh './deploy.sh production'
            }
        }
    }
}

L’étape input met le pipeline en pause et attend qu’un humain approuve le déploiement en production — un garde-fou qui prévient les releases accidentelles.

Pièges et Cas Limites

Jenkins manque d’espace disque : Les anciens builds accumulent artefacts et logs. Configurez la rétention des builds dans les paramètres du job (discard old builds) et mettez en place un cron pour nettoyer l’espace de travail : jenkins-cli delete-builds job-name --range 1-100.

Le pipeline se bloque sur l’étape input : Si personne n’approuve, le pipeline occupe un executor indéfiniment. Définissez un timeout : timeout(time: 30, unit: 'MINUTES') { input ... }.

Permissions sur le socket Docker : Lorsque Jenkins tourne dans Docker avec le socket Docker monté, l’utilisateur jenkins doit avoir accès à /var/run/docker.sock. Ajoutez l’utilisateur jenkins au groupe docker ou ajustez les permissions du socket.

Restrictions du sandbox Groovy : Les pipelines déclaratifs s’exécutent dans un sandbox Groovy qui bloque certaines opérations. Si vous avez besoin de Groovy sans restrictions (I/O fichiers, appels réseau), le pipeline doit être approuvé par un admin sous Manage Jenkins > Script Approval.

Conflits de versions de plugins : Jenkins compte 1800+ plugins qui peuvent parfois entrer en conflit. Verrouillez les versions des plugins et testez les mises à jour sur une instance Jenkins de staging avant de mettre à jour la production.

Résolution de Problèmes

Le pipeline échoue avec “No such DSL method”

// Cette erreur signifie qu'un plugin requis n'est pas installé
// Vérifiez que les plugins Pipeline, Git et Docker Pipeline sont installés
// Manage Jenkins > Plugins > Installed plugins

L’espace de travail du build grossit trop

// Ajoutez une étape de nettoyage à votre pipeline
post {
    always {
        cleanWs()    // Supprimer l'espace de travail après le build
    }
}

Les déclenchements webhook ne fonctionnent pas

# Vérifier que Jenkins est accessible depuis votre fournisseur Git
curl -I http://your-jenkins:8080/github-webhook/

# Consulter le journal système Jenkins pour les événements webhook
# Manage Jenkins > System Log > All Jenkins Logs

Résumé

• Les pipelines Jenkins définissent votre processus CI/CD sous forme de code dans un Jenkinsfile qui vit dans votre dépôt Git aux côtés de votre application
• La syntaxe déclarative avec les blocs pipeline, stages et steps est l’approche recommandée — plus facile à lire, à valider et à maintenir que les pipelines scriptés
• Les agents Docker exécutent chaque stage dans un conteneur vierge, garantissant des environnements de build cohérents et éliminant les problèmes “ça marche sur ma machine”
• Utilisez le Credentials Manager pour tous les secrets — ne codez jamais en dur mots de passe, tokens ou clés SSH dans les Jenkinsfiles
• Les pipelines multi-branches avec les conditions when { branch } et when { tag } appliquent automatiquement des règles de déploiement différentes selon la branche
• Configurez la rétention des builds et le nettoyage de l’espace de travail pour éviter que Jenkins ne consomme tout l’espace disque disponible avec le temps

Articles Connexes

• Débuter avec GitHub Actions pour CI/CD
• Docker Compose : Guide Pratique pour Administrateurs Système
• Terraform : Débuter avec l’Infrastructure as Code
• Ansible pour Débutants : Automatiser la Configuration Serveur sans Agent