Jenkins : découvrons l’outil CI/CD référence en entreprise

Habitué à GitHub Actions pour tous mes pipelines, j’ai voulu comprendre pourquoi Jenkins reste autant utilisé en entreprise. Voici un résumé de ce que j’ai appris.

C’est quoi le CI/CD, et pourquoi c’est important

Le CI/CD (Intégration Continue / Déploiement Continu) permet d’automatiser deux choses essentielles dans le cycle de vie d’un logiciel :

  • L’intégration continue : à chaque changement de code, on lance automatiquement des tests, du lint, des vérifications de qualité, etc.
  • Le déploiement continu : une fois le code validé, il est déployé automatiquement (ou semi-automatiquement) vers un environnement (staging, production…).

L’avantage principal : les tests automatisés couvrent un périmètre bien plus large et plus profond que ce qu’on pourrait tester manuellement, tout en supprimant les erreurs humaines et en accélérant les livraisons.

Pourquoi Jenkins précisément

Jenkins est un serveur d’automatisation open source. Quelques raisons qui expliquent sa popularité persistante en entreprise :

  • Gratuit et open source : pas de coût de licence.
  • Installable partout : on-premise, cloud, sur son propre serveur, contrairement à un outil lié à une plateforme SaaS spécifique.
  • Écosystème de plugins énorme : des plugins gratuits pour à peu près tout (tests, déploiement, notifications, intégrations avec d’autres outils…).
  • Pas seulement pour le code applicatif : Jenkins peut aussi automatiser des tâches système.
  • Prérequis : Jenkins tourne sur Java.

Se connecter au serveur Jenkins (SSH et CLI)

Jenkins expose une interface en ligne de commande (CLI) accessible par SSH. Dans mon cas :

  1. Connexion en root, puis bascule vers un utilisateur dédié.
  2. Dans ~/.ssh/, une paire de clés (privée/publique) est déjà présente.
  3. La clé publique est ajoutée dans l’interface Jenkins : compte utilisateur → Security → SSH Public Keys.
  4. Cela permet ensuite de se connecter au serveur CLI Jenkins via une commande du type :
ssh -i /home/ismo/.ssh/jenkins_key -l ismo -p 8022 jenkins-server help

Le port 8022 est le port dédié à la CLI Jenkins (différent du port web habituel, souvent 8080). Cette commande help liste les commandes CLI disponibles.

Démarrer le service

Jenkins tourne comme un service système classique, démarré avec :

systemctl start jenkins

JENKINS_HOME

JENKINS_HOME est le dossier principal de Jenkins : il contient la configuration, les jobs, les plugins, l’historique des builds, etc. C’est le dossier prioritaire à sauvegarder, car il concentre l’essentiel de l’état de l’instance.

Sauvegarder Jenkins : le plugin ThinBackup

Pour la formation, la méthode utilisée est le plugin ThinBackup, avec ces étapes :

  1. Créer un dossier dédié pour les sauvegardes, par exemple /var/lib/jenkins/jenkins_backup (le chemin exact dépend du type d’installation).
  2. Donner les droits nécessaires sur ce dossier (chmod 777 a été utilisé dans le cadre de la formation, à adapter/durcir en environnement réel).
  3. Configurer le plugin pour qu’il sauvegarde régulièrement JENKINS_HOME vers ce dossier.

(ThinBackup n’est pas forcément la seule solution du marché, mais c’est celle choisie pour cette formation.)

Le Jenkinsfile : définir un pipeline

Le Jenkinsfile est le fichier qui décrit un pipeline (build, tests, lint, déploiement…). Sa structure de base ressemble à :

pipeline {
    agent any

    environment {
        // variables d'environnement
    }

    stages {
        stage('Build') {
            steps {
                // commandes
            }
        }
        stage('Test') {
            steps {
                // commandes
            }
        }
        stage('Deploy') {
            steps {
                // commandes
            }
        }
    }
}

Quelques notions clés :

  • agent : où le pipeline s’exécute (par exemple un node agent).
  • stages / stage : les grandes étapes du pipeline (build, test, deploy…).
  • steps : les actions concrètes à l’intérieur de chaque stage.
  • On peut avoir un pipeline multi-stage, avec plusieurs façons de l’organiser : soit un seul fichier qui contient tous les stages (build, test, run…), soit les stages répartis dans différents fichiers.

Venant de GitHub Actions, la logique m’a semblé assez familière : on retrouve ce découpage en étapes, avec un vocabulaire différent mais des concepts proches.

Interface graphique ou ligne de commande ?

Une question que je me suis posée : en entreprise, utilise-t-on plutôt l’interface web ou la CLI pour piloter Jenkins ?

En pratique, c’est un mix des deux : l’interface web est très utilisée pour la configuration, la visualisation des builds et la gestion des plugins, tandis que la CLI (et surtout le Jenkinsfile versionné dans le repo) sert davantage à l’automatisation et à l’intégration dans les workflows DevOps. Le Jenkinsfile en lui-même, écrit en Groovy, est la vraie « source de vérité » du pipeline, que ce soit configuré via l’UI ou en ligne de commande au départ.

En résumé : Jenkins reste incontournable en entreprise pour son autonomie (auto-hébergé), sa gratuité, son écosystème de plugins massif et sa flexibilité (Jenkinsfile en Groovy). La logique de pipeline (stages/steps) rejoint celle de GitHub Actions, ce qui facilite la transition d’un outil à l’autre.

Publications similaires