Construisez votre premier pipeline déclaratif Jenkins pour CI/CD

Votre premier pipeline déclaratif Jenkins devrait répondre à une question pratique : Jenkins peut-il vérifier votre code, le construire, le tester et exécuter les étapes de déploiement uniquement lorsque la bonne branche réussit ? Un Jenkinsfile vous offre ce flux de travail sous forme de code dans le même dépôt que votre application.

La syntaxe déclarative est un bon point de départ car elle offre une structure prévisible : pipeline, agent, stages, steps et post.

Comprendre la structure du pipeline déclaratif

Le pipeline déclaratif définit l'ensemble du flux de travail dans un fichier nommé Jenkinsfile, qui est stocké avec le code de votre application dans votre dépôt SCM (par exemple, Git). Cette pratique est connue sous le nom de Pipeline as Code.

Éléments essentiels d'un pipeline déclaratif

Un pipeline déclaratif doit contenir les blocs de niveau supérieur suivants :

1. pipeline : Le bloc externe obligatoire définissant le contenu du pipeline.
2. agent : Spécifie où le pipeline ou une étape spécifique s'exécutera (par exemple, any, none ou des étiquettes spécifiques).
3. stages : Contient un ou plusieurs blocs stage séquentiels.
4. stage : Définit un bloc conceptuel de travail (par exemple, Build, Test, Deploy).
5. steps : Contient une ou plusieurs commandes ou fonctions exécutées dans un stage.

pipeline {
    agent any 
    environment { // Optionnel : Définit les variables d'environnement
        APP_VERSION = '1.0.0'
    }
    stages {
        stage('Build') {
            steps {
                // Les commandes vont ici
            }
        }
    }
    post { // Optionnel : Actions exécutées après la fin du pipeline
        always { 
            echo 'Pipeline terminé.' 
        }
    }
}

Étape 1 : Configurer le job Jenkins

Pour exécuter un pipeline à partir du code, vous devez configurer un job Jenkins pour lire le Jenkinsfile depuis votre dépôt.

1. Accédez à votre tableau de bord Jenkins et sélectionnez Nouvel élément.
2. Saisissez un nom pour votre pipeline (par exemple, mon-premier-pipeline-ci).
3. Sélectionnez le type d'élément Pipeline et cliquez sur OK.
4. Dans la page de configuration, faites défiler jusqu'à la section Pipeline.
5. Modifiez la définition de Pipeline script à Pipeline script from SCM.
6. Sélectionnez votre SCM (par exemple, Git).
7. Saisissez l'URL du dépôt et configurez vos identifiants si nécessaire.
8. Assurez-vous que le Chemin du script est défini sur Jenkinsfile (par défaut).

Étape 2 : Définir le Jenkinsfile pour CI/CD

Nous allons créer un Jenkinsfile complet qui simule un flux de travail CI/CD simple, intégrant des étapes standard pour un déploiement réussi.

Supposons que vous ayez une structure de dépôt contenant le code source de votre application (par exemple, un projet Python ou Java simple) et le Jenkinsfile à la racine.

Exemple complet de pipeline déclaratif

Ce pipeline utilise l'agent node (s'il est configuré) et utilise des étapes shell de base (sh) pour simuler un travail réel. L'étape de déploiement est conditionnelle, s'exécutant uniquement après la réussite des étapes précédentes.

// Jenkinsfile
pipeline {
    // 1. Définition de l'agent : Spécifie où l'ensemble du pipeline s'exécute
    agent { 
        label 'mon-agent-de-build' // Utilisez une étiquette spécifique si disponible, ou 'any'
    }
    
    // 2. Variables d'environnement : Définit les variables utilisables dans tout le pipeline
    environment {
        CONTAINER_REGISTRY = 'registry.example.com'
        IMAGE_NAME = 'myapp'
    }
    
    stages {
        
        // Étape 1 : Checkout (Gestion du code source)
        stage('Checkout Source') {
            steps {
                // L'étape 'checkout scm' vérifie automatiquement le code 
                // en fonction de la configuration définie dans les paramètres du job Jenkins.
                checkout scm
                sh 'echo "Code source vérifié avec succès."'
            }
        }
        
        // Étape 2 : Construction des artefacts
        stage('Build Artifact') {
            steps {
                sh 'echo "Démarrage de la construction pour $IMAGE_NAME:$BUILD_ID"'
                // Simulation : Construire une image Docker ou compiler un fichier jar/war
                sh "docker build --label build_id=${BUILD_ID} -t ${CONTAINER_REGISTRY}/${IMAGE_NAME}:${BUILD_ID} ."
            }
        }
        
        // Étape 3 : Tests et portes de qualité
        stage('Run Tests') {
            steps {
                sh './run_unit_tests.sh'
                sh 'echo "Exécution des tests d'intégration..."'
                // Exemple de collecte des résultats de test (nécessite des plugins appropriés)
                // junit '**/target/surefire-reports/*.xml'
            }
        }
        
        // Étape 4 : Déploiement (Conditionnel)
        stage('Deploy to Staging') {
            // La directive 'when' garantit que l'étape ne s'exécute que sous des conditions spécifiques
            when {
                branch 'main'
            }
            steps {
                sh "docker push ${CONTAINER_REGISTRY}/${IMAGE_NAME}:${BUILD_ID}"
                sh 'kubectl apply -f k8s/deployment-staging.yaml'
                script {
                    // Les blocs Script permettent une logique Groovy traditionnelle dans les étapes déclaratives
                    echo "Déploiement réussi dans l'environnement de staging."
                }
            }
        }
    }
    
    // 3. Actions post : Définit les actions en fonction du statut final du pipeline
    post {
        success {
            echo 'Pipeline terminé avec succès. Notification de l\'équipe via Slack...'
            // slackSend channel: '#devops-alerts', message: 'CI/CD Réussi !'
        }
        failure {
            echo 'Pipeline échoué. Vérifiez les journaux pour les erreurs.'
        }
        cleanup {
            sh 'docker image prune -f --filter "label=build_id=$BUILD_ID"'
        }
    }
}

Étape 3 : Exécuter et surveiller le pipeline

Une fois le Jenkinsfile validé et poussé vers la branche configurée dans votre job Jenkins :

1. Sur la page du job Jenkins, cliquez sur Build Now (ou attendez le polling SCM/déclencheur webhook).
2. Surveillez la construction dans le panneau Build History.
3. Cliquez sur le numéro de construction en cours et sélectionnez Console Output pour voir les détails de l'exécution étape par étape.
4. Vous pouvez également utiliser la visualisation Stage View (si le plugin est installé) pour voir graphiquement la progression des étapes Checkout, Build, Test et Deploy.

Bonnes pratiques et fonctionnalités avancées

Utilisation de bibliothèques et de code partagé

Pour des étapes complexes ou très répétitives, évitez d'écrire du Groovy verbeux directement dans le Jenkinsfile. Utilisez plutôt des bibliothèques partagées. Ces bibliothèques externes vous permettent de définir des fonctions courantes (comme des routines de déploiement standard ou des fonctions de notification) qui peuvent être appelées depuis plusieurs pipelines, rendant votre Jenkinsfile plus propre.

// Appel d'une étape de bibliothèque partagée
stage('Configuration personnalisée') {
    steps {
        customLibrary.initializeEnvironment(env: 'prod')
    }
}

Travailler avec les identifiants

Ne codez jamais en dur des informations sensibles (mots de passe, jetons, clés API) directement dans le Jenkinsfile. Utilisez le système de gestion des identifiants intégré de Jenkins.

L'étape withCredentials vous permet d'accéder en toute sécurité aux secrets stockés :

stage('Authentification au registre') {
    steps {
        withCredentials([usernamePassword(credentialsId: 'docker-registry-creds', 
                                          passwordVariable: 'PASS', 
                                          usernameVariable: 'USER')]) {
            sh '''
                printf '%s' "$PASS" | docker login \
                  --username "$USER" \
                  --password-stdin "$CONTAINER_REGISTRY"
            '''
        }
    }
}

Sélection de l'agent

Conseil : Définissez toujours votre agent spécifiquement en utilisant une label plutôt que agent any. Utiliser agent any signifie que le pipeline pourrait s'exécuter sur le nœud contrôleur Jenkins, ce qui est un risque de sécurité et peut impacter les performances du contrôleur. Assurez-vous d'avoir configuré correctement des agents Jenkins (nœuds) avec les outils nécessaires (Docker, Maven, Node.js) installés.

À retenir

Gardez le premier pipeline simple et fiable : choisissez une étiquette d'agent réelle, vérifiez le code, construisez, testez, conditionnez le déploiement par branche et conservez les secrets dans les identifiants Jenkins. Une fois que cela fonctionne, ajoutez la publication d'artefacts, l'analyse de sécurité et la promotion d'environnement une étape à la fois.