Etape 2 : Build - Compiler le code (exemple conceptuel, ex: `mvn compile` ou `npm install`)

La transformation du code : qu'est-ce que l'étape de build ?

Une fois le code source récupéré lors de l'étape de Checkout, le pipeline CI passe à une phase de transformation essentielle : l'étape de Build. C'est ici que le code brut, tel qu'écrit par les développeurs, est traité pour devenir une forme plus tangible, souvent un artefact exécutable, une bibliothèque, ou un ensemble de fichiers prêts à être déployés ou testés. Cette étape est le coeur de la création de la valeur logicielle, transformant les instructions en un produit potentiel.

Le terme "Build" est générique et recouvre une vaste gamme d'opérations. La nature exacte des actions entreprises durant cette étape dépend intimement de la technologie et du langage de programmation utilisés pour le projet. Pour un projet Java, cela impliquera typiquement une compilation du code source en bytecode. Pour une application Node.js, il pourrait s'agir de télécharger les dépendances ou de transpiler du TypeScript en JavaScript. Pour une application web statique, le build pourrait consister à minifier des fichiers CSS et JavaScript ou à générer des pages HTML à partir de templates.

Les objectifs principaux de l'étape de build sont multiples. Il s'agit premièrement de vérifier que le code source est syntaxiquement correct et qu'il peut être transformé en un produit fonctionnel (par exemple, qu'il compile sans erreur). Deuxièmement, le build produit souvent des artefacts, qui sont les livrables du processus : un fichier .jar ou .war pour Java, un répertoire dist pour une application frontend, une image Docker, etc. Ces artefacts seront ensuite utilisés par les étapes suivantes du pipeline, comme les tests ou le déploiement.

Exemples concrets de commandes de build dans un pipeline Jenkins

Dans un pipeline Jenkins, l'étape de build est généralement exécutée via des commandes shell (sh sous Linux/macOS) ou des commandes batch (bat sous Windows) qui invoquent les outils de construction spécifiques au projet. L'agent Jenkins qui exécute le pipeline doit disposer de ces outils (JDK, Maven, Node.js, npm, etc.) dans son environnement.

Pour un projet Java utilisant Maven, une commande de build typique est mvn compile pour compiler les sources, ou plus couramment mvn package pour compiler et empaqueter le résultat dans un fichier JAR ou WAR. Voici comment cela pourrait apparaître dans un Jenkinsfile :

pipeline {
    agent any // Assurez-vous que l'agent a Maven et JDK configurés
    stages {
        stage('Checkout') {
            steps {
                git url: 'https://votre-depot.git/votre-projet-java.git', branch: 'main'
            }
        }
        stage('Build') {
            steps {
                echo 'Compilation du projet Java avec Maven...'
                // Pour Unix/Linux
                sh 'mvn clean package'
                // Pour Windows, ce serait bat 'mvn clean package'
            }
        }
        // Etape de Test à suivre
    }
}

L'utilisation de clean avant package est une bonne pratique pour s'assurer que le build part d'un état propre, supprimant les artefacts des builds précédents.

Pour un projet Node.js, la commande npm install est fondamentale pour télécharger toutes les dépendances listées dans le fichier package.json. Si le projet est une application frontend (React, Angular, Vue.js) ou utilise un processus de build (transpilation, minification), une commande comme npm run build est souvent utilisée. Voici un exemple pour Node.js :

pipeline {
    agent any // Assurez-vous que l'agent a Node.js et npm configurés
    stages {
        stage('Checkout') {
            steps {
                git url: 'https://votre-depot.git/votre-projet-node.git', branch: 'main'
            }
        }
        stage('Build') {
            steps {
                echo 'Installation des dépendances et build du projet Node.js...'
                sh 'npm install'
                // Si votre package.json a un script "build" :
                // sh 'npm run build' 
            }
        }
        // Etape de Test à suivre
    }
}

Ces exemples sont conceptuels mais illustrent le principe. D'autres technologies auront leurs propres commandes : docker build . -t mon-image pour construire une image Docker, python setup.py build pour un projet Python, ou l'appel à un compilateur comme gcc pour du C/C++. L'essentiel est d'identifier la commande qui, dans votre contexte projet, transforme le code source en un produit prêt pour la suite. Le choix de l'agent Jenkins (et des outils qui y sont installés ou mis à disposition, par exemple via un conteneur Docker spécifié dans la directive agent) est donc crucial pour le succès de cette étape.

Considérations clés pour une étape de build efficace

La réussite de l'étape de build dépend fortement de l'environnement d'exécution. L'agent Jenkins doit avoir accès à tous les outils nécessaires (compilateurs, runtimes, gestionnaires de paquets) et aux versions correctes de ceux-ci. L'utilisation d'agents Docker, où l'environnement de build est défini dans une image Docker, est une pratique de plus en plus courante pour garantir la cohérence et la reproductibilité de l'environnement de build, quel que soit l'agent physique qui exécute la tâche.

Une autre considération importante est la gestion des sorties du build, c'est-à-dire les artefacts. Une fois le build terminé avec succès, les fichiers produits (par exemple, .jar, .war, binaires, archives compressées) doivent souvent être conservés. Jenkins permet d'archiver ces artefacts. Ils peuvent ensuite être téléchargés manuellement, utilisés par d'autres jobs, ou déployés dans les étapes ultérieures du pipeline. La directive archiveArtifacts est utilisée à cette fin.

Enfin, il est primordial que l'étape de build soit aussi rapide et efficiente que possible. Des builds longs ralentissent la boucle de feedback pour les développeurs. Des stratégies comme la mise en cache des dépendances (par exemple, le cache local de Maven ou npm) peuvent significativement accélérer les builds. Si un build échoue, il doit le faire clairement et rapidement, en fournissant des logs explicites pour faciliter le diagnostic. Cette étape est un gardien : si le code ne peut pas être construit correctement, il est inutile de passer aux tests ou au déploiement.