Rédiger un Jenkinsfile simple avec les étapes Checkout, Build, Test

La structure d'un Jenkinsfile déclaratif : simplicité et clarté

Le Jenkinsfile est le coeur de l'approche "Pipeline as Code" dans Jenkins. Pour les débutants, la syntaxe Déclarative est la plus accessible car elle offre une structure claire et prédéfinie. Un Jenkinsfile déclaratif de base s'articule autour de quelques blocs essentiels : pipeline, agent, et stages. Chacun de ces blocs a un rôle précis dans la définition de votre processus d'automatisation.

L'objectif ici est de créer un Jenkinsfile minimaliste mais fonctionnel qui illustre les trois étapes fondamentales d'un pipeline CI :

1. Checkout : Récupérer le code source depuis un SCM (Source Code Management), typiquement Git.
2. Build : Compiler ou préparer le code source (par exemple, installer des dépendances, transpiler du code).
3. Test : Exécuter les tests automatisés (par exemple, tests unitaires) pour valider la qualité du code.

Nous allons simuler les actions de build et de test avec des commandes simples pour nous concentrer sur la structure du Jenkinsfile. Dans un projet réel, vous remplacerez ces commandes par celles spécifiques à votre technologie (mvn, npm, docker, etc.).

Exemple de Jenkinsfile déclaratif avec Checkout, Build, et Test

Voici un exemple de Jenkinsfile simple. Ce fichier, nommé Jenkinsfile (sans extension), devrait être placé à la racine de votre dépôt Git si vous configurez votre job Pipeline pour utiliser "Pipeline script from SCM". Si vous utilisez l'option "Pipeline script" directement dans l'interface Jenkins, vous pouvez copier-coller ce contenu.

// Début du bloc pipeline, le conteneur principal de notre définition.
pipeline {
    // 'agent any' signifie que Jenkins peut exécuter ce pipeline sur n'importe quel agent disponible.
    // Pour des besoins spécifiques (ex: un agent avec Docker, Node.js, ou Java), 
    // on pourrait spécifier un label d'agent particulier ou une configuration d'agent Docker.
    agent any 

    // La section 'stages' contient une ou plusieurs étapes (stages) qui composent le pipeline.
    // Les étapes sont exécutées séquentiellement.
    stages {
        // Définition de la première étape : Checkout
        stage('Checkout') {
            steps {
                // La section 'steps' contient les actions à exécuter pour cette étape.
                echo '1. Récupération du code source...'
                
                // Si ce Jenkinsfile est chargé depuis Git ("Pipeline script from SCM"),
                // Jenkins a déjà cloné le dépôt dans le workspace au moment où cette étape démarre.
                // La commande 'checkout scm' est souvent implicite dans ce cas.
                // Pour plus de clarté ou pour des configurations SCM multiples/complexes, on peut l'expliciter.
                // checkout scm 
                
                // Pour un exemple auto-contenu ou si le SCM n'est pas configuré au niveau du job :
                // Vous devriez remplacer cela par une vraie commande git si vous n'utilisez pas 'Pipeline script from SCM'.
                // Par exemple :
                // git url: 'https://github.com/votre-utilisateur/votre-projet.git', branch: 'main'
                
                // Pour cet exemple, on va juste afficher le contenu du répertoire pour simuler le checkout.
                sh 'echo "Code source (simulé) récupéré. Contenu du workspace :"'
                sh 'ls -la'
            }
        }

        // Définition de la deuxième étape : Build
        stage('Build') {
            steps {
                echo '2. Compilation / Préparation du code...'
                
                // Commandes de build simulées.
                // Remplacez par vos commandes réelles, par exemple :
                // sh 'mvn clean package' // Pour un projet Java avec Maven
                // sh 'npm install && npm run build' // Pour un projet Node.js/frontend
                sh 'echo "Exécution des commandes de build (ex: mvn compile, npm install)..."'
                sh 'mkdir -p build_output' // Crée un répertoire pour simuler un artefact
                sh 'echo "Ceci est un artefact produit par le build" > build_output/mon_artefact.txt'
                echo 'Build terminé. Artefact simulé créé dans build_output/.'
            }
        }

        // Définition de la troisième étape : Test
        stage('Test') {
            steps {
                echo '3. Exécution des tests unitaires...'
                
                // Commandes de test simulées.
                // Remplacez par vos commandes réelles, par exemple :
                // sh 'mvn test' // Pour un projet Java avec Maven
                // sh 'npm test' // Pour un projet Node.js
                sh 'echo "Exécution des tests (ex: mvn test, npm test)..."'
                
                // Simuler un succès de test
                // Dans un vrai scénario, si 'npm test' ou 'mvn test' échoue, 
                // la commande 'sh' retournera un code d'erreur non nul, 
                // et Jenkins marquera cette étape (et donc le pipeline) comme échouée.
                sh 'echo "Tous les tests (simulés) sont passés avec succès !"'
            }
        }
    }

    // La section 'post' est optionnelle. Elle permet de définir des actions à exécuter 
    // après la fin de toutes les étapes (stages), en fonction du statut du pipeline.
    post {
        always { // S'exécute toujours, que le pipeline ait réussi ou échoué.
            echo 'Pipeline terminé. Exécution des actions post-build.'
            // Exemple: Nettoyage du workspace (attention, cela supprime tout !)
            // cleanWs()
        }
        success { // S'exécute uniquement si toutes les étapes ont réussi.
            echo 'Le pipeline a réussi ! Prêt pour la prochaine étape (ex: déploiement).' 
        }
        failure { // S'exécute uniquement si au moins une étape a échoué.
            echo 'Le pipeline a échoué. Veuillez vérifier les logs.'
            // Exemple: Envoyer une notification d'échec
            // mail to: 'equipe-dev@example.com', subject: "Echec du Pipeline: ${currentBuild.fullDisplayName}", body: "Le pipeline a échoué. Consultez les logs ici : ${env.BUILD_URL}"
        }
        // D'autres conditions comme 'unstable', 'changed', 'aborted' sont aussi disponibles.
    }
}

Explication des composants clés du Jenkinsfile

pipeline { ... } : C'est le bloc racine qui englobe toute la définition d'un pipeline déclaratif. Tout votre script doit être contenu à l'intérieur de ces accolades.

agent any : Cette directive spécifie sur quel type d'agent Jenkins le pipeline (ou une étape spécifique) doit s'exécuter. agent any signifie que Jenkins peut utiliser n'importe quel agent disponible configuré dans votre système Jenkins. Pour des besoins plus spécifiques (comme une version particulière de Java, Node.js, ou la présence de Docker), vous pouvez spécifier un label d'agent (agent { label 'mon-agent-special' }) ou utiliser un agent Docker (agent { docker 'maven:3.8.1-jdk-11' }).

stages { ... } : Cette section contient une série d'une ou plusieurs directives stage. Les stages représentent les grandes phases logiques de votre pipeline (comme Checkout, Build, Test, Deploy). Ils sont exécutés séquentiellement par défaut.

stage('Nom de l'Etape') { ... } : Chaque bloc stage définit une étape distincte. Le nom que vous lui donnez (par exemple, 'Checkout', 'Build', 'Test') apparaîtra dans l'interface utilisateur de Jenkins (Stage View, Blue Ocean) pour visualiser la progression du pipeline.

steps { ... } : A l'intérieur de chaque stage, la section steps contient les commandes ou actions réelles à exécuter. Vous pouvez y inclure une ou plusieurs instructions. Les types d'instructions courantes sont :

• echo 'message' : Affiche un message dans la sortie console du build. Très utile pour le débogage et le suivi.
• sh 'commande shell' : Exécute une commande shell sur les agents de type Unix/Linux/macOS. Pour Windows, vous utiliseriez bat 'commande batch'. C'est ainsi que vous interagissez avec vos outils de build, de test, SCM, etc.
• git : Une instruction spécifique pour interagir avec les dépôts Git (cloner, pousser, etc.). Souvent utilisée lorsque le Jenkinsfile n'est pas chargé via "Pipeline script from SCM" ou pour des opérations Git plus complexes.
• checkout scm : Une instruction spéciale qui utilise la configuration SCM définie au niveau du job Pipeline pour récupérer le code. Si votre Jenkinsfile est chargé depuis un SCM, cette action est souvent implicite ou réalisée par Jenkins avant même l'exécution de la première étape de votre script, mais il peut être nécessaire de l'appeler explicitement dans certains scénarios ou pour cloner des dépôts supplémentaires.

post { ... } : Cette section optionnelle définit des actions à exécuter après la fin de l'ensemble des stages. Elle contient des blocs conditionnels (always, success, failure, unstable, changed, aborted) qui permettent d'exécuter des étapes de nettoyage, de notification, ou d'archivage d'artefacts en fonction du résultat global du pipeline.

Ce Jenkinsfile simple constitue une excellente base. Pour l'adapter à un projet réel, vous devrez remplacer les commandes sh de simulation par les véritables commandes nécessaires pour cloner votre code spécifique, le compiler avec vos outils (mvn, gradle, npm, pip, docker build, etc.), et exécuter vos suites de tests (mvn test, npm test, pytest, etc.). Vous pourrez ensuite l'enrichir avec des étapes supplémentaires comme l'analyse statique de code, la construction d'images Docker, le déploiement sur des environnements, et bien plus encore.