Passer de Jenkins à GitLab CI : Guide complet et cas concret de migration

Introduction

Avec l’essor du DevOps et de l’intégration continue, les outils de CI/CD sont devenus indispensables pour automatiser les tests, les builds et les déploiements. Jenkins s’est longtemps imposé comme une référence historique. Cependant, des solutions plus intégrées comme GitLab CI gagnent du terrain grâce à leur simplicité et leur approche tout-en-un.

Dans cet article, nous allons :

• Introduire Jenkins et GitLab CI

• Comparer leurs usages, avantages et limites

• Étudier un cas concret de migration d’une pipeline Jenkins vers GitLab CI

Présentation et comparatif des outils

Jenkins : le pionnier de la CI/CD

Jenkins est un serveur d’intégration continue open source créé en 2011 (fork de Hudson). Il permet d’automatiser :

• Les builds applicatifs

• Les tests automatisés

• Les déploiements

• Les tâches planifiées

Caractéristiques principales

• Installation sur serveur (on-premise ou cloud)

• Configuration via interface web ou fichiers Jenkinsfile

• Écosystème très riche de plugins

• Grande flexibilité de personnalisation

Jenkins est particulièrement apprécié dans les environnements complexes ou historiques où tout est fortement sur mesure.

GitLab CI : la CI/CD intégrée au dépôt Git

GitLab CI est la solution d’intégration continue native de GitLab. Elle est directement intégrée au gestionnaire de code source et se base sur un fichier.gitlab-ci.yml versionné avec le projet.

Caractéristiques principales

• CI/CD intégrée au repository

• Pipelines déclenchées à chaque commit / merge request

• Runners distribués (Docker, VM, Kubernetes…)

• Configuration as Code simple en YAML

GitLab CI s’inscrit dans une logique DevOps unifiée : code, CI, sécurité et déploiement au même endroit.

Comparatif Jenkins vs GitLab CI

Avantages / Inconvénients

Cas concret : Migration d’une pipeline Jenkins vers GitLab CI

Pipeline Jenkins (Jenkinsfile)

Traduction en GitLab CI (gitlab-ci.yml)

Décryptage des correspondances clés

Voici ce que chaque concept Jenkins devient dans GitLab CI, et pourquoi c'est différent, pas juste comment :

1. Credentials → Variables CI/CD

Avec Jenkins, les credentials sont gérés via un plugin dédié et nécessitent une syntaxe withCredentials([...]) parfois verbeuse. Dans GitLab CI, les secrets sont définis dans Settings > CI/CD > Variables et injectés automatiquement comme variables d'environnement dans tous les jobs. Le gain : aucune configuration dans le code, et les variables peuvent être masquées, protégées (accessibles uniquement sur branches protégées) ou scoped par environnement.

Contexte

Prenons une application web Node.js avec une pipeline typique en production :

1. Installation des dépendances

2. Lint

3. Tests unitaires

4. Build

5. Déploiement sur environnement de staging

L'objectif n'est pas seulement de "traduire" le Jenkinsfile, mais de tirer parti des fonctionnalités natives de GitLab CI pour obtenir une pipeline plus robuste, plus lisible et plus maintenable.

3.

2.

Jenkins s'appuie sur un plugin JUnit pour parser les résultats de tests. GitLab CI intègre ce parsing nativement : les résultats apparaissent directement dans l'interface des Merge Requests, avec le détail de chaque test passé/échoué, sans plugin à installer ni à maintenir.

La directive rules: de GitLab CI est plus puissante que le when de Jenkins : elle permet de conditionner un job sur la branche, sur une variable, sur le type d'événement (push, MR, schedule, tag...), ou sur des combinaisons de ces critères.

Pièges à anticiper lors de la migration

Quelques points d'attention concrets pour éviter les mauvaises surprises :

Les timeouts par défaut diffèrent. GitLab CI applique un timeout de 60 minutes par job par défaut. Si certains jobs Jenkins dépassaient cette limite (builds lourds, tests d'intégration longs), il faut penser à ajuster : timeout: 2h au niveau du job.

Les variables d'environnement ne sont pas toutes identiques. Jenkins expose BUILD_NUMBER, GIT_BRANCH, etc. GitLab CI utilise ses propres variables prédéfinies (CI_PIPELINE_ID, CI_COMMIT_BRANCH...). Un simple audit des variables utilisées dans les scripts de déploiement évite des erreurs silencieuses.

Le comportement du cache peut surprendre. Sur un runner partagé (GitLab SaaS), le cache n'est pas garanti entre deux jobs si ceux-ci s'exécutent sur des runners différents. Il vaut mieux traiter le cache comme une optimisation facultative et s'assurer que la pipeline fonctionne correctement même sans lui.

4. Cache intelligent

Dans Jenkins, le cache entre builds est souvent géré via le workspace persistant de l'agent, ce qui peut provoquer des états corrompus difficiles à diagnostiquer. GitLab CI propose un cache basé sur une clé de hachage (ici le package-lock.json) : le cache est automatiquement invalidé si les dépendances changent, ce qui élimine toute une classe de bugs de CI "ça marche sur ma machine".

Aller plus loin : parallélisation des tests

L'un des gains concrets de GitLab CI sur Jenkins pour les projets intermédiaires à grands, c'est la facilité de parallélisation. Là où Jenkins nécessite une configuration d'agents multiples et une coordination manuelle, GitLab CI offre un mot-clé natif :

Chaque runner reçoit automatiquement son index (CI_NODE_INDEX) et le total (CI_NODE_TOTAL), ce qui permet au framework de test de diviser la charge. Résultat : sur une suite de 400 tests qui prend 8 minutes en séquentiel, on tombe à ~2 minutes.

Bénéfices observés après migration

Conclusion

Ce que ce cas concret nous enseigne vraiment

Au-delà de la traduction mécanique d'un Jenkinsfile en .gitlab-ci.yml, ce qui ressort de cette migration c'est la réduction de la charge cognitive pour toute l'équipe. Avec Jenkins, la CI est un outil à part, maintenu par quelques personnes, souvent opaque pour les autres. Avec GitLab CI, la pipeline vit dans le repo, elle se lit, se review et se débogue comme du code — ce qui change profondément la dynamique d'équipe.

Notre recommandation

Arrêtez de traiter la migration comme un risque. Pour la grande majorité des projets web — et particulièrement les stacks Node.js, Python ou conteneurisées — GitLab CI couvre 95 % des besoins avec bien moins de maintenance. Le vrai risque, c'est de continuer à payer le coût silencieux de Jenkins : les plugins qui cassent, les agents à patcher, les onboardings ralentis.

Réservez Jenkins aux cas où vous avez des contraintes d'infra très spécifiques, un SI legacy profondément intégré, ou des pipelines qui exploitent des plugins sans équivalent GitLab.

Par où commencer ?

Ne cherchez pas à tout migrer d'un coup. Identifiez une pipeline secondaire, traduisez-la en .gitlab-ci.yml en suivant les correspondances de cet article, faites-la tourner en parallèle pendant deux semaines, puis basculez. La migration progressive est la meilleure façon de lever les doutes sans bloquer la production.