Migrer de Jenkins vers GitLab : le guide complet

GitLab est la plateforme DevSecOps alimentée par l'IA la plus complète. En effet, GitLab fournit toutes les fonctionnalités dont vous avez besoin pour planifier, développer et livrer des logiciels sécurisés plus rapidement, le tout au sein d'une seule et même plateforme.

Les plateformes comme GitLab éliminent les difficultés et les défis liés à l'intégration de multiples outils (approche DevOps DIY) pour gérer au mieux le cycle de vie du développement logiciel (SDLC). À l'inverse, Jenkins n'étant pas une plateforme, des outils supplémentaires sont nécessaires pour compléter le SDLC. Cette approche DevOps DIY introduit une complexité supplémentaire liée à la chaîne d'outils, et génère un certain nombre d'inconvénients comme :

• La nécessité d'une assistance personnalisée pour l'intégration et l'orchestration des outils
• La difficulté à tenir à jour/mettre à niveau/sécuriser des outils disparates
• L'impossibilité de mesurer correctement la transformation organisationnelle
• Une mauvaise expérience des équipes de développement
• Des coûts supplémentaires en lien avec la gestion, les délais et le budget
• Une perte de productivité
• Un changement de contexte et une inefficacité en terme de collaboration

Pour ces raisons, de nombreuses équipes de développement utilisant Jenkins envisagent de migrer vers une plateforme DevSecOps complète. Si vous recherchez une plateforme puissante, fiable et sécurisée, GitLab est votre meilleure option ! GitLab propose une version gratuite ainsi que différents niveaux d'abonnement en fonction des besoins de votre entreprise. Pour en savoir plus sur nos offres et fonctionnalités, consultez notre page tarifaire.

Découvrez dans cet article de blog :

• Comment planifier une migration
• Comment migrer des dépôts depuis d'autres outils de gestion du code source (SCM) vers GitLab
• Comment migrer des pipelines CI/CD de Jenkins vers GitLab

Comment planifier une migration de Jenkins vers GitLab ?

Avant d'initier la migration de vos dépôts hébergés sur un autre outil vers GitLab CI/CD, vous devez élaborer un plan de migration. Cette étape technique est importante et vous permet de définir clairement vos attentes. Les outils CI/CD diffèrent par leur approche, leur structure et leurs spécificités techniques. Par conséquent, les migrations ne sont pas de simples transferts directs des données.

Un plan de migration offre les avantages suivants :

• Il définit et communique une vision claire de vos objectifs de migration, ce qui aide les personnes impliquées à comprendre le but de cette opération.
• Il vous permet de vous assurer d’obtenir l'aval des équipes de direction concernées pour faciliter cette démarche.
• Il permet d'expliquer aux utilisateurs les changements à venir.
• Il permet de trouver des moyens de séquencer ou de retarder certaines étapes de la migration pour éviter l'échec de la migration ou une migration partielle.
• Il documente les avantages des améliorations apportées par GitLab CI/CD et met à jour votre mise en œuvre à chaque étape de la migration.

Un plan de migration vous aide à mettre en place un processus fluide permettant de migrer progressivement vers GitLab, avec un minimum de perturbations. Il peut s'agir d’exécuter simultanément Jenkins et GitLab, tandis que certains projets sont transférés de Jenkins vers GitLab.

Définissez un processus de gestion du changement

Il se peut que les développeurs, opérateurs informatiques, administrateurs cloud, équipes en charge de la sécurité, ainsi que les ingénieurs qualité n'aient pas d'expérience avec GitLab et ne sachent pas pourquoi vous ou votre équipe de direction avez choisi de réaliser cette migration. C'est pourquoi votre plan de migration doit inclure un processus efficace de gestion du changement.

Les personnes impactées par cette migration doivent savoir :

• Pourquoi ce changement est nécessaire
• À quoi ressemblera le futur système
• Comment l'entreprise prévoit d'atteindre cet objectif
• Vers qui se tourner pour obtenir plus d'informations ou de l'aide

À cette fin, vous devez réaliser les étapes suivantes afin de gérer efficacement le changement au sein des différentes équipes fonctionnelles :

• Analysez l'état actuel : documentez les processus existants. Collectez des indicateurs qui serviront de base de référence. Identifiez ce qui fonctionne ou non avec l'approche CI/CD en interrogeant certains membres de votre équipe. Documentez les défis que vous devez relever, et ce d'un point de vue quantitatif et qualitatif. Comme vous allez devoir expliquer les raisons de ce changement et votre vision, plus vous définirez clairement les problématiques que vous espérez résoudre, plus il vous sera facile d'obtenir l'adhésion de tous.
• Établissez une vision : maintenant que vous avez décrit les points de friction actuels quantitativement avec des indicateurs de référence et qualitativement (en vous basant sur les retours des membres de votre équipe), communiquez une vision de l'état futur. Expliquez pourquoi c'est important (en vous référant aux indicateurs de réussite de votre entreprise) et partagez l’état actuel de la situation et les résultats attendus. Renforcez ce message par le biais de différents canaux de communication : groupes de discussion, réunions rassemblant l'ensemble des acteurs de l'entreprise, ou encore notifications par e-mail.
• Formez les collaborateurs : investissez dans une formation sur GitLab CI/CD dispensée par un expert GitLab. Mesurez l'acquisition et la mémorisation des connaissances à l'aide des certifications GitLab.
• Communiquez la roadmap et les ressources : partagez avec les membres de votre équipe le calendrier prévu de la migration et les ressources mises à leur disposition pour faciliter la transition. Mentionnez également les ressources communautaires (groupes de discussion, forums), afin que votre équipe puisse poser des questions et obtenir de l'aide. Créez un système qui récompense les équipes qui effectuent rapidement cette transition, et encouragez-les à partager leur expérience avec d'autres équipes similaires au sein de l'entreprise.

Si vous mettez en place ces éléments dès le début de cette transition, cela sera de bon augure pour la réussite de votre migration.

Définissez des objectifs de migration

Avant d'effectuer votre migration, vous devez avoir une bonne compréhension de vos objectifs et de la façon de les atteindre. Voici par exemple certaines des questions auxquelles vous devez pouvoir répondre :

• Quel est votre calendrier de migration ?
• Quelle est la configuration actuelle de votre serveur Jenkins ?
• Combien de projets sont concernés par la migration ?
• Quel est le degré de complexité de votre pipeline ?
• Nécessite-t-il des dépendances externes, plusieurs déclencheurs pour s'exécuter, exécute-t-il plusieurs processus en parallèle pour compiler le code, etc. ?
• Comment/où déployez-vous votre code ?
• Quel est le processus de revue/sortie des nouvelles versions et de déploiement du code ?
• Est-il intégré dans Jenkins ou dans un workflow distinct déclenché par Jenkins ?
• Quels artefacts de compilation ou binaires sont nécessaires au succès du pipeline ?
• Quels plug-ins sont utilisés par les jobs dans Jenkins aujourd'hui ?
• Quel logiciel est installé sur les agents Jenkins ?
• Quelle solution de gestion du code source (SCM) utilisez-vous actuellement ?
• Utilisez-vous des bibliothèques partagées dans vos jobs Jenkins ?
• Quelle méthode d'authentification est utilisée pour Jenkins (Basic Authentication, LDAP/AD, SSO) ?
• Y a-t-il d'autres projets auxquels vous devez accéder depuis votre pipeline ?
• Des identifiants de connexion dans Jenkins sont-ils utilisés pour accéder à des services externes ?

En répondant à ces questions, vous saurez comment procéder à la migration, combien de temps durera cette opération et par où commencer. Une fois que vous avez élaboré un plan et que vous êtes conscient des attentes et des écueils possibles, vous pouvez commencer votre processus de migration.

Prérequis à la migration

Une fois que vous avez créé votre plan de migration et répondu à toutes les attentes associées, vous pouvez commencer à configurer GitLab.

Voici certains des prérequis suggérés pour la migration :

• Familiarisez-vous avec GitLab et découvrez les fonctionnalités clés de GitLab CI/CD.
• Suivez des tutoriels pour créer votre premier pipeline GitLab et des pipelines plus complexes qui créent, testent et déploient un site statique.
• Passez en revue la liste des mots-clés de configuration .gitlab-ci.yml.
• Configurez GitLab.
• Testez votre instance GitLab.

Une fois que vous avez compris le fonctionnement de GitLab et qu'une instance a été configurée, vous pouvez suivre votre plan de migration et commencer à déplacer des projets de Jenkins vers GitLab. Vérifiez que votre instance GitLab a été correctement configurée à l'aide des bonnes pratiques et des architectures de référence de GitLab.

Migrez vos dépôts vers GitLab

L'un des principaux inconvénients de Jenkins est qu'il ne fournit pas de solution SCM. Si vous utilisez Jenkins, votre code doit être stocké dans une solution SCM distincte à laquelle Jenkins doit avoir accès. Comme GitLab dispose d'un SCM intégré, la migration depuis Jenkins vous permet également de migrer depuis la solution SCM que vous utilisiez, ce qui entraîne une réduction supplémentaire des coûts.

GitLab fournit des outils pour vous permettre de déplacer facilement votre dépôt et ses métadonnées dans GitLab. Les outils d'importation suivants sont inclus et vous aideront à migrer vos projets vers GitLab :

• GitHub
• Autre instance GitLab
• Bitbucket Cloud
• Bitbucket Server
• FogBugz
• Gitea
• Jira (Tickets uniquement)
• Dépôt par fichier manifeste
• Dépôt par URL

Chaque outil d'importation importe différentes données d'un projet. Lisez notre documentation sur l'importation et la migration de projets pour en savoir plus sur les outils d'importation fournis et comprendre quelles données sont migrées vers GitLab. De plus, vous pouvez automatiser l'importation de groupes et de projets et créer une solution personnalisée pour mieux répondre aux besoins de votre entreprise :

• Services professionnels
• Services de migration
• Foire aux questions sur la migration

Comment migrer un dépôt ?

La migration d'un dépôt vers GitLab est facile grâce à nos outils d'importation intégrés. Dans cet exemple, nous allons vous expliquer comment copier un dépôt de GitHub vers GitLab ainsi que ses ressources (tickets, pull requests, jalons et plus encore).

Afin de migrer un dépôt depuis GitHub vers GitLab, vous pouvez suivre les étapes ci-dessous :

1. Dans la barre latérale de gauche, en haut, sélectionnez Créer un nouveau (+).
2. Sélectionnez Nouveau projet/dépôt.
3. Sélectionnez Importer un projet.

4. Cliquez sur le bouton GitHub.
   • Si vous utilisez GitLab Self-Managed, vous devez activer l'outil d'importation GitHub.
   • Notez que d'autres outils d'importation peuvent être lancés de la même manière.
5. Vous pouvez ensuite utiliser l'une des deux options ci-dessous :
   • Autoriser OAuth de GitHub en sélectionnant Autoriser avec GitHub.
   • Utiliser un jeton d'accès personnel GitHub :
     • Accédez à la page https://github.com/settings/tokens/new.
     • Dans le champ Note, saisissez une description du token.
     • Sélectionnez la portée du dépôt.
     • En option, pour importer des collaborateurs, sélectionnez la portée read:org.
     • Cliquez sur le bouton Générer un token.
     • Sur la page d'importation de GitLab, dans le champ Jeton d'accès personnel, collez le jeton d'accès personnel GitHub.
6. Cliquez sur le bouton Authentification.
7. Sélectionnez les éléments que vous souhaitez migrer.
8. Sélectionnez les projets que vous souhaitez migrer et leur destination.
9. Cliquez sur le bouton Importer.

Le projet importé devrait maintenant être disponible dans votre espace de travail. Pour en savoir plus sur la migration de GitHub vers GitLab, regardez cette vidéo :

Une fois que vous avez terminé la migration de votre dépôt, vous pouvez configurer votre pipeline Jenkins pour exploiter le fichier Jenkinsfile dans GitLab. Pour ce faire, définissez l'URL du dépôt sur le projet que vous venez tout juste d'importer via le menu de configuration du pipeline Jenkins :

Cette opération est utile pendant la phase de migration initiale du dépôt et vous permet d'utiliser Jenkins et GitLab en parallèle. Vous évitez ainsi toute interruption de service pendant que vous travaillez sur votre migration.

De plus, vous pouvez utiliser le plug-in Jenkins GitLab pour faciliter la migration. Ce plug-in permet à GitLab de déclencher et d'obtenir le statut des compilations Jenkins.

Migrez vos pipelines CI/CD

Une fois que vous avez migré vos dépôts vers GitLab, vous pouvez procéder à la migration de vos pipelines Jenkins. Bien qu'assez simple, ce processus nécessite une bonne compréhension des concepts et de la syntaxe Jenkins et GitLab.

Jenkins fournit deux types de syntaxe pour la définition des pipelines : une syntaxe déclarative et une syntaxe scriptée. Dans ce guide, nous décrirons la migration à partir des pipelines déclaratifs, car ils sont les plus couramment utilisés.

Migrez votre pipeline étape par étape

Dans ce tutoriel, nous analyserons un fichier Jenkinsfile (Groovy) ainsi qu'un fichier de configuration GitLab CI/CD (YAML) qui compile, teste et déploie un microservice écrit en Golang. Nous activerons ensuite le pipeline dans GitLab et observerons le résultat.

Le pipeline :

• Utilisera l'image de conteneur Golang avec le tag alpine
• Exécutera un job pour compiler le code Golang en un fichier binaire exécutable
  • Stockera le fichier exécutable compilé en tant qu'artefact
• Exécutera un job pour lancer les tests unitaires
• Exécutera un job pour effectuer le déploiement sur l'environnement de préproduction
  • Ne s'exécutera que si la validation cible la branche de préproduction
  • S'exécutera uniquement après la réussite de l'étape de test
  • Utilisera l'artefact exécutable compilé du job précédent

Vous trouverez ci-dessous les définitions de pipeline Jenkins et GitLab accompagnées de commentaires descriptifs. Vous pouvez observer le pipeline en action dans le projet de migration Meow.

Voici un fichier Jenkinsfile écrit en Groovy :

// The top-level of the declarative
// pipeline.
pipeline {

  // Defines the default agent to use
  // when it is not explicitly defined
  // in a job.
    agent any

  // Defines the stages that will run
  // in numerical order. Each stage
  // only runs one job.
    stages {

    // Defines the name of the stage
        stage('build') {
      // Defines the container image to
      // use for this job, overwriting
      // the default 'agent any'.
      // The Jenkins Docker plugin
      // must be configured for this
      // to run.
            agent { docker 'golang:alpine' }

      // Defines the sequence of steps
      // to execute when the stage is
      // run.
            steps {
                sh 'go build -o bin/meow-micro'
                sh 'chmod +x bin/meow-micro'
            }

      // The steps to run after the
      // stage completes.
            post {
              always {

        // Stores the stage artifacts
        // generated for use in another
        // job.
                archiveArtifacts artifacts: 'bin/meow-micro'
                onlyIfSuccessful: true
              }
            }
        }

    stage('test') {
            agent { docker 'golang:alpine' }
            steps {
                sh 'go test .'
            }
        }

        stage('deploy') {
      // Defines conditions which must
      // be met in order for the job to
      // execute. In this case the
      // deploy job will only run on the 
      // staging branch.
            when {
              branch 'staging'
            }
            steps {
                echo 'Deploying meow-micro to staging'
        // Uses the artifact stored in
        // the build stage.
                sh './bin/meow-micro'
            }
        }
    }
}

Voyons maintenant comment créer la même fonctionnalité dans GitLab :

# Defines the default image to use
# when it is not explicitly defined in
# a job.
default:
  image: alpine:latest

# Defines the order to run the stages.
# Each stage can have multiple jobs.
stages:
  - build
  - test
  - deploy

# Defines the name of the job
create-binary:
 # Defines the stage the job will run in
  stage: build
 # Defines the container image to use
 # for this job, overwriting default.
  image: golang:alpine
 # Defines the sequence of steps to
 # execute when the job is run.
  script:
    - go build -o bin/meow-micro
    - chmod +x bin/meow-micro
 # Stores the job artifacts generated
 # for use in another job.
  artifacts:
    paths:
      - bin/meow-micro
    expire_in: 1 week

unit-tests:
  stage: test
  image: golang:alpine
  script:
    - go test .
 # Defines commands to run after the
 # job.
 after_script:
  - echo "Tests Complete"

staging-deploy:
  stage: deploy
 # Defines commands to run before the
 # actual job.
  before_script:
    - apk update
  script:
    - echo "Deploying meow-micro to staging environment"
    - ./bin/meow-micro
 # Defines conditions which must be met
 # in order for this job to execute. In
 # this case the staging-deploy job will 
 # only run on the staging branch.
  rules:
    - if: $CI_COMMIT_BRANCH == 'staging'
 # Allows the artifact stored in the
 # build job to be used in this job.
  artifacts:
    paths:
      - bin/meow-micro

Comme vous l'avez peut-être remarqué, il existe de nombreuses similitudes entre Jenkins et GitLab en termes de syntaxe, ce qui simplifie la migration du pipeline. Bien que l'exemple ci-dessus fournisse une vue d'ensemble basique, assurez-vous de consulter la liste complète des comparaisons de fonctionnalités et de concepts entre les deux outils.

Maintenant que nous comprenons comment transposer Jenkins à GitLab, nous pouvons commencer à créer un pipeline avec les mêmes fonctionnalités dans GitLab. Pour effectuer la migration de votre pipeline CI/CD, suivez les étapes suivantes :

1. Ouvrez le dépôt que vous avez migré vers GitLab dans la section ci-dessus.

• Dans la barre latérale de gauche, en haut, sélectionnez Rechercher ou accéder à...
• Localisez votre projet.

2. Ouvrez l'éditeur de pipeline.

• Dans la barre latérale de gauche, sélectionnez Compilation > Éditeur de pipeline.

• Cliquez sur le bouton Configurer le pipeline.

3. Complétez le fichier .gitlab-ci.yml.

• Ajoutez le code du pipeline GitLab CI.

• Vérifiez que la syntaxe est correcte.

• Visualisez le pipeline.

4. Validez le fichier dans la branche principale.

• Ajoutez un message de validation.
• Assurez-vous que la branche est définie sur la branche principale.
• Cliquez sur le bouton Valider les modifications.

Une fois le fichier fusionné, le pipeline défini s'exécute. Vous pouvez revenir à votre projet et observer le pipeline en action en le sélectionnant sur la page Compilation > Pipelines de votre projet. Comme il a été exécuté sur la branche principale, vous ne verrez que les jobs create-binary et unit-tests. Le job staging-deploy s'exécute uniquement sur la branche de préproduction.

Si nous créons une branche de préproduction, le pipeline suivant s'exécute.

En cliquant sur un job, nous pouvons voir la sortie associée :

L'artefact est stocké dans le job create-binary et utilisé dans le job staging-deploy. Et voilà, la migration d'un pipeline de Jenkins vers GitLab est aussi simple que cela !

Autres conseils à suivre lors de la migration

Voici quelques conseils pratiques pour simplifier le processus de déploiement :

• N'essayez pas de répliquer les tâches dans des jobs GitLab une à une. Prenez le temps de comprendre le fonctionnement du pipeline actuel et quel problème il résout.

• Certains jobs Jenkins peuvent être trop complexes pour être migrés immédiatement vers GitLab. Il peut donc s'avérer pratique d'utiliser le plug-in Jenkins GitLab pour lancer les pipelines Jenkins et afficher leurs résultats directement depuis GitLab. Cela vous permet de migrer lentement certaines actions vers GitLab jusqu'à ce que l'ensemble du pipeline puisse être déplacé.

• Mettez en œuvre des scanners de sécurité et une vérification de la qualité du code à l'aide de templates intégrés fournis par GitLab. Cela vous permettra d'intégrer la sécurité en amont et ainsi de réduire le risque potentiel de failles. Simplifiez votre configuration CI/CD et essayez d'utiliser les avantages de chaque fonctionnalité sans tarder. Modularisez le code et implémentez-le en petites itérations.

• Mettez en place le suivi et la gouvernance dès le départ.

• Sachez que GitLab Runner (Go) peut se comporter différemment de l'agent Jenkins (Java). L'utilisation du processeur et la consommation de mémoire peuvent différer. Pensez à effectuer des comparaisons au fil du temps.

• Envisagez d'investir dans des mécanismes de mise à l'échelle automatique et arrêtez les ressources inutiles le week-end ou en dehors des heures de travail.

• Modernisez le développement d'applications en conteneurisant vos jobs. Les jobs Jenkins ne sont pas actuellement exécutés sur un conteneur, mais sur un agent Jenkins s'exécutant en tant que machine virtuelle.

Bien que cette liste ne soit pas exhaustive, elle constitue un bon point de départ. Si vous avez besoin d'une aide supplémentaire, GitLab fournit des services professionnels pour vous aider dans votre parcours de migration.

Conclusion

Merci de votre intérêt pour cet article ! Nous espérons que ce guide vous a aidé à comprendre les avantages d'une migration de Jenkins vers GitLab, et comment procéder.

Vous hésitez encore ? Essayez GitLab gratuitement et découvrez les avantages de notre plateforme DevSecOps.

Ressources complémentaires :

• Migration depuis Jenkins
• Planification d'une migration
• Outils d'importation de projets GitLab
• Migrer de GitHub Advanced Security vers GitLab Ultimate : notre guide complet
• Vidéo : Migration facile de GitHub vers GitLab
• De Jenkins vers GitLab : le guide ultime pour moderniser votre environnement CI/CD