Intégration de Jenkins avec les outils populaires : un aperçu pratique

Jenkins devient utile lorsqu'il peut communiquer avec les outils que votre équipe utilise déjà : Git pour le code, Docker pour les images, les frameworks de test pour les retours et les dépôts d'artefacts pour les versions. L'objectif n'est pas d'installer tous les plugins que vous pouvez trouver. L'objectif est de construire un pipeline clair qui récupère le code, le construit, le teste et publie le résultat.

Cet aperçu pratique montre comment les intégrations Jenkins s'assemblent généralement et où les équipes commettent souvent des erreurs.

Commencez par le contrôle de source

La plupart des pipelines Jenkins commencent par un checkout Git. Dans un job Pipeline, Jenkins peut soit utiliser le dépôt configuré dans le job et exécuter checkout scm, soit vous pouvez définir le dépôt dans le Jenkinsfile.

Pour un Pipeline multibranche, cela suffit généralement :

pipeline {
    agent any

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

Les jobs multibranches découvrent les branches et les pull requests depuis GitHub, GitLab, Bitbucket ou un autre serveur Git, selon les plugins que vous installez et configurez.

Pour un job Pipeline simple, vous pouvez voir un checkout explicite :

git url: 'https://github.com/example/app.git', branch: 'main'

Utilisez les identifiants Jenkins pour les dépôts privés. Ne mettez pas de jetons dans l'URL du dépôt.

Préférez les webhooks au polling

Jenkins peut interroger Git pour détecter les changements, mais les webhooks sont plus propres. Votre fournisseur Git envoie une requête à Jenkins lorsque quelqu'un pousse du code ou ouvre une pull request, et Jenkins démarre le job correspondant.

Une configuration typique ressemble à ceci :

Installez le plugin Jenkins pour votre fournisseur Git, comme GitHub Branch Source ou GitLab Branch Source.
Créez un job Pipeline multibranche.
Ajoutez la source du dépôt ou de l'organisation.
Stockez les identifiants dans Jenkins Credentials.
Ajoutez l'URL du webhook dans les paramètres de votre fournisseur Git.

Le polling fonctionne toujours pour les réseaux restreints, mais il ajoute du délai et une charge inutile.

Construisez et poussez des images Docker

Jenkins peut construire des images Docker tant que l'agent exécutant le build a accès à Docker. Cela peut être une VM avec Docker installé, un agent Kubernetes avec un outil de build comme Kaniko ou BuildKit, ou une configuration de socket Docker contrôlée.

Voici un flux simple de construction et de push Docker :

pipeline {
    agent any

    environment {
        IMAGE = 'registry.example.com/team/app'
    }

    stages {
        stage('Build Image') {
            steps {
                sh 'docker build -t $IMAGE:$BUILD_NUMBER .'
            }
        }

        stage('Push Image') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'registry-login',
                    usernameVariable: 'REGISTRY_USER',
                    passwordVariable: 'REGISTRY_PASSWORD'
                )]) {
                    sh '''
                        echo "$REGISTRY_PASSWORD" | docker login registry.example.com \
                          --username "$REGISTRY_USER" --password-stdin
                        docker push "$IMAGE:$BUILD_NUMBER"
                    '''
                }
            }
        }
    }
}

Le détail important est --password-stdin. Cela évite d'exposer le mot de passe du registre dans la ligne de commande et est plus sûr que docker login -p.

Exécutez des tests et publiez les résultats

Jenkins n'a pas besoin de comprendre votre framework de test pour l'exécuter. Il a besoin que votre commande de build produise un format de rapport que Jenkins peut lire.

Pour un projet Maven avec des rapports XML de style JUnit :

pipeline {
    agent any

    stages {
        stage('Test') {
            steps {
                sh 'mvn test'
            }
            post {
                always {
                    junit 'target/surefire-reports/*.xml'
                }
            }
        }
    }
}

Le bloc post { always { ... } } est important. Il publie les résultats des tests même en cas d'échec, afin que vous puissiez voir les échecs dans l'interface utilisateur de Jenkins.

Les projets Python, JavaScript et Go peuvent utiliser le même motif s'ils émettent des rapports compatibles. Par exemple, de nombreuses équipes Python exécutent pytest --junitxml=reports/junit.xml, puis publient reports/junit.xml.

Stockez les sorties de build dans un dépôt d'artefacts

Ne traitez pas un espace de travail Jenkins comme un stockage à long terme. Les espaces de travail sont temporaires et peuvent disparaître lorsque les agents sont nettoyés.

Utilisez un dépôt d'artefacts tel que Nexus, Artifactory, un registre de conteneurs ou un stockage objet cloud pour les sorties de version. Jenkins peut archiver de petits fichiers de diagnostic avec archiveArtifacts, mais les packages de production doivent aller dans un système conçu pour la rétention et le contrôle d'accès.

Exemple pour conserver les logs de build ou les rapports avec l'exécution :

post {
    always {
        archiveArtifacts artifacts: 'reports/**', allowEmptyArchive: true
    }
}

Utilisez cela pour les preuves de build, pas comme votre seul dépôt de version.

Gardez les identifiants dans Jenkins, pas dans les pipelines

Jenkins Credentials peut stocker des noms d'utilisateur, mots de passe, clés SSH, jetons et fichiers secrets. Votre pipeline doit faire référence à un credentialsId, pas à la valeur secrète.

Pour les commandes shell, liez les identifiants uniquement autour de l'étape qui en a besoin :

withCredentials([string(credentialsId: 'slack-webhook', variable: 'SLACK_WEBHOOK')]) {
    sh 'curl -X POST -H "Content-type: application/json" --data "{\"text\":\"Build complete\"}" "$SLACK_WEBHOOK"'
}

Gardez la portée petite. Cela réduit le risque de fuite de secrets via les logs ou les commandes ultérieures.

Intégrations utiles à ajouter plus tard

Une fois le pipeline de base stable, ajoutez des intégrations en fonction des besoins réels du workflow :

Type d'outil	Utilisation courante
Fournisseur Git	Découverte de branches, builds de pull requests, mises à jour de statut de commit
Docker ou constructeur d'images	Construire et publier des images conteneur
Rapport de tests	Afficher les échecs, les tendances et les tests instables
Dépôt d'artefacts	Stocker les sorties de build et les packages de version
Outils de chat ou d'incidents	Notifier le bon canal en cas d'échec ou de version réussie
Scanners de sécurité	Vérifier les dépendances, les images ou le code source avant la version

Ajoutez une intégration à la fois et assurez-vous que le pipeline échoue toujours clairement. Une configuration Jenkins utile est ennuyeuse dans le meilleur sens : un développeur pousse du code, Jenkins le construit, le teste, publie l'artefact et montre exactement où un échec s'est produit.