Maximize Page
Tech & DevOps HubEspace Tech & DevOps: Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussions Explore the world of development, the cloud and DevOps tools

Introduction à GitLab: Analyse et préparation du projet Flashcards app

Date de l'article:21-05-2026
CI/CD Gitlab
Découvrez les fondations nécessaires à la mise en place progressive d'une chaîne CI/CD GitLab pour une application Java. Suivez sa progression, de l'analyse jusqu'à l'automatisation de sa CI/CD.
INFO PROJET
App Flashcards - readme CI
Container Registry
Qualité/couverture : sonarCloud project SonarQube Cloud
Follow-up
Dans ce premier article, nous analysons les workflows GitHub existants, puis nous préparons le dépôt GitLab en définissant la stratégie avant d'écrire le moindre pipeline.
L'objectif premier est de préparer un socle propre avant d'implémenter les différents contrôles.
Présentation générale de l'application
Cette implémentation s'appuie sur une application Flashcards, servant de terrain d'expérimentation pour mettre en œuvre différentes pratiques DevOps.
Une première série d'articles présentait la mise en place complète de la chaîne CI/CD avec GitHub Actions ainsi que les étapes préparatoires aux tests.
L'application inclut entre autres: des tests automatisés, l'analyse statique du code, les mesures de couverture, l'analyse de sécurité, la construction d'image Docker, des tests fonctionnels d'API, un test de charge ainsi que la publication d'artefacts, de rapports et d'images.
Cette série reprend cette même application afin d'implémenter une chaîne CI/CD équivalente avec GitLab CI/CD.
Ces deux dépôts entraînent un coût de maintenance, mais ils permettent de comparer concrètement les deux plateformes et leurs mécanismes natifs.
À terme, les deux implémentations couvriront les mêmes exigences fonctionnelles, tout en conservant une configuration CI/CD spécifique à chaque plateforme.
Répartition des responsabilités
Le dépôt GitHub est la référence fonctionnelle de l'application
Il contient le code source de l'application, ses workflows, les scripts communs utilisés par les différentes plateformes. Vous pouvez suivre l'évolution de la CI/CD via son tableau de suivi GitHub Actions.
Mise à jour de l'application
Lorsqu'une évolution est apportée à l'application, les modifications sont répercutées dans le dépôt GitLab afin que les deux environnements puissent bénéficier des mêmes évolutions et correctifs.
GitHub
│
├── .github
│    //..
└── Application + scripts CI
       │              │
       └──────────────│
                      │
GitLab                │
│                     │
├── Même application ─┘
└── .gitlab
GitLab: une implémentation CI/CD indépendante
Si la logique métier doit rester identique dans les deux dépôts, les fichiers de pipeline et la configuration propres à chaque plateforme sont, en revanche, maintenus séparément. Son tableau de suivi est également disponible.
GitLab est l'une des plateformes les plus utilisées. Elle offre des fonctionnalités et une approche différentes de celles de GitHub. C'est dans sa version gratuite que je l'utiliserai pour ce projet.
Analyse des workflows GitHub (par branche)
Puisque l'application contient déjà plusieurs tests ainsi que plusieurs dépendances, il est utile, à ce stade, d'identifier précisément ce que réalise déjà la chaîne CI.
Cette analyse permettra d'identifier: les outils qui pourront être conservés, ceux qui devront être adaptés à GitLab, les dépendances nécessaires à chaque job et les artefacts à transmettre entre les étapes du pipeline.
L'objectif est de comprendre les contrôles attendus sur chaque branche afin de reconstruire un flux équivalent avec les mécanismes propres à GitLab.
develop
Objectif: fournir un feedback rapide. 
name: CI - Develop
jobs:
└── build-and-test
    ├── Checkout du code
    ├── Configuration du JDK 17
    ├── Vérification Spotless
    ├── Checkstyle
    ├── SpotBugs
    ├── Analyse CodeQL
    ├── Tests unitaires et d'intégration
    ├── Génération du rapport JaCoCo
    └── Scan Trivy du système de fichiers
Cette branche vérifie rapidement la qualité du code et la réussite des tests avant l'intégration des modifications.
staging
Objectifs : tester l'API et la charge 
name: CI - Staging
jobs:
├── build-test-static-analysis
│   ├── Démarrage de PostgreSQL 16
│   ├── Spotless, Checkstyle et SpotBugs
│   ├── Tests unitaires
│   ├── Tests d'intégration
│   ├── Rapport JaCoCo
│   ├── Construction du fichier JAR
│   ├── Analyse CodeQL
│   └── Scan Trivy du système de fichiers
├── functional-tests
│   ├── Téléchargement du fichier JAR
│   ├── Scan de l'image Docker
│   ├── Démarrage du conteneur Flashcards
│   ├── Vérification de l'endpoint Actuator
│   ├── Installation de Node.js et Newman
│   └── Exécution des tests d'API
└── load-tests
    ├── Téléchargement du fichier JAR
    ├── Démarrage de l'application Spring
    ├── Installation de k6
    └── Exécution des tests de charge
main
Objectifs : produire et publier une version livrable. 
name: Prod Build,..
jobs:
  │
  ├── Tests et génération du rapport JaCoCo
  ├── Analyse CodeQL
  ├── Scan Trivy du système de fichiers
  ├── Calcul d'un identifiant court du commit
  ├── Construction de l'image Docker
  ├── Scan de l'image Docker
  ├── Publication du rapport SonarCloud
  │
  ├── Smoke tests du conteneur
  │   ├── Vérification de /actuator/health
  │   └── Vérification de /api/categories
  └── Publication de l'image dans le Gitlab
                         Container Registry
Conclusions de l'analyse et plans de départ
GitLab CI/CD ne repose pas sur des Actions.
Il s'appuie sur sa propre mécanique de jobs, de pipelines et de runners, configurée notamment via le fichier .gitlab-ci.yml placé à la racine du dépôt et exécutée par des GitLab Runners. Pour réutiliser du code entre projets, GitLab propose un catalogue dédié qui permet de publier et de découvrir ses composants CI/CD.
Afin de rester dans l'écosystème de sécurité proposé par GitLab,
j'intégrerai "Semgrep" en tant qu'analyseur SAST (à la place de CodeQL), et nous verrons également les différentes manières de l'intégrer aux pipelines.
Je reproduirai tous les tests de l'application: les tests UT/IT, Postman/Newman et K6, ainsi que les publications SonarCloud, afin d'éviter d'introduire inutilement d'autres services. Pour la publication d'image j'utiliserai le Container Registry de Gitlab afin de ne pas faire entrer en collision les versions existantes.
Je reproduirai aussi la création automatique de Merge Requests, bien utile entre chaque branche. La seule différence est que, dans GitLab, nous ne développerons qu'un seul fichier pipeline, qui traitera les deux environnements.

De manière générale, GitLab ne fonctionne pas exactement comme GitHub, et c'est ce que nous allons explorer au travers des articles de cette série.

Dans une perspective multiplateforme, Renovate sera utilisé pour gérer les mises à jour automatiques des dépendances.
À ce jour, GitHub utilise Dependabot, natif de sa plateforme.
L'ordre prévu est d'intégrer Renovate dans le dépôt GitLab, de valider son fonctionnement et d'appliquer une configuration adaptée à sa plateforme.
Mise en place du projet GitLab
Le dépôt GitLab sera créé à partir d'un clone du dépôt GitHub, puis maintenu séparément. Je ne toucherai pas à l'application, on se concentre uniquement sur la CI/CD.
1. Cloner le dépôt GitHub
(Git Bash, depuis votre emplacement de travail) 
git clone https://github.com/val7304/flashcards.git flashcards_gitlab
cd flashcards_gitlab
2. Créer le dépôt sur GitLab
RV sur GitLab, connectez-vous ou créez votre compte.
  • Nouveau projet: Choisissez "Créer un projet vierge"
  • Donnez-lui un nom, définissez la visibilité, puis validez
  • Copiez l'URL HTTPS (ou SSH) du nouveau dépôt
3. Ajouter le remote GitLab
git remote set-url origin https://gitlab.com/user/flashcards.git
  Vérifier le remote 
git remote -v
Résultat attendu: 
origin  https://gitlab.com/user/flashcards.git (fetch)
origin  https://gitlab.com/user/flashcards.git (push)
4. Pousser le code sur GitLab
Supprimer tout le dossier .github, il ne nous servira pas. 
git rm -r .github/*

Puis, poussez les branches et les tags:

git push origin --all
git push origin --tags
5. Créer la branche develop (local)
Vérifiez les branches disponibles : 
git branch -a
Positionnez-vous sur develop : 
git switch develop
Créez la branche de travail : 
git switch -C feature/gitlab-ci
git status
RV sur GitLab → votre projet, pour vérifier qu'il a bien été poussé et qu'il contient les branches.
Pour ce projet, nous utilisons la stratégie "GitLab Flow" et procédons ainsi:
→ une branche feature/* est créée à partir de develop → les modifications sont poussées sur GitLab
→ une Merge Request est ouverte vers develop, après validation, la branche est fusionnée et promue vers staging, puis main
Tester l'application
Voir les prérequis
En local, vous devez disposer de PostgreSQL 16 et de Java 17, au minimum, pour lancer l'application. Ainsi, vous pourrez exécuter la majeure partie des tests, tester les profils, Actuator, etc. (informations dans le readme)
Si vous faites des modifications, ce projet utilise Spotless et vous devez exécuter la commande de formatage automatique avant de pousser le code sur GitLab.
Cette vérification est importante, car le pipeline pourra bloquer si le code ne respecte pas les règles de formatage.
Configuration GitLab
1. Les branches protégées
La protection des branches permet de limiter les push directs et d'imposer le passage par une Merge Request.
Le but est d'obliger la validation par d'autres développeurs (peer review) en empêchant qu'un code non testé ou cassé n'arrive directement en production via le pipeline.
Configuration des règles
Créons la règle pour la branche staging pour l'instant, avec cette même configuration. Nous protégerons develop lorsque le pipeline de base fonctionnera.
Depuis le projet: Settings → Repository → Branch rules
→ Choisissez la branche à sécuriser dans le menu déroulant (staging)
→ Définissez le niveau d'autorisation pour :
"Allowed to merge: Developers + Maintainers"
"Allowed to push and merge: No one" pour interdire les push directs
→ Cliquez sur le bouton de validation pour enregistrer
"main" étant la branche principale, elle est protégée selon les paramètres initiaux du projet
État actuel (et par défaut) 
Branch rules  2
All branches  3 matching branches
Squash commits: Allow

main  defaultprotected
Allowed to merge: Developers and Maintainers
Allowed to push and merge: No one
GitLab documente la configuration: pour imposer le passage par une Merge Request,
il faut régler Allowed to push and merge sur No one, puis autoriser les rôles appropriés dans Allowed to merge.
2. Les variables CI/CD

Nous allons reprendre les mêmes noms de variables que sur GitHub pour faciliter les choses.
Les tokens sont aussi réutilisables, puisqu'il s'agit de tokens externes ou de mots de passe présents dans l'application.

Masked    → empêche la valeur de s'afficher dans les logs lorsque GitLab peut l'identifier.
Protected → limite l'utilisation de la variable aux pipelines exécutés dans un contexte autorisé par les branches/tags protégés.
Depuis le projet: Settings → CI/CD → Variables
Key Protected Masked
POSTGRES_PASSWORD
DOCKERHUB_USERNAME
DOCKERHUB_TOKEN
SONAR_TOKEN
Vérification du runner
Avant de construire un pipeline complet, il est utile de vérifier que le projet peut exécuter un job avec un runner disponible.
Pour cela, on va identifier quel type de runner est utilisé.
1. Créer un pipeline minimal
Utilisez le "Pipeline Editor" de l'interface pour éditer et valider le fichier avant de le committer: Depuis le Projet Build → Pipeline Editor
Le but est d'avoir le pipeline vert pour pouvoir visualiser ses logs.
Créer le fichier .gitlab-ci.yml, à la racine du projet, avec juste: 
stages:
  - test
hello:
  stage: test
  script:
    - echo "Hello GitLab"
2. Voir le runner utilisé
Rendez-vous sur le job exécuté, via le menu: Build → Pipelines
Cliquez sur le job "hello" pour voir son exécution et ses logs :
Dans ce cas, le job a été exécuté par un runner GitLab hébergé, identifié dans les logs par : 4-blue.saas-linux-small-amd64
Cela confirme que le projet peut commencer avec un runner hébergé par GitLab, sans installer immédiatement de runner local.
Le choix d'un runner dédié sera toutefois pertinent car la série nécessitera:
Docker-in-Docker, des outils spécifiques, un accès à un réseau privé, des volumes persistants et une configuration reproductible maîtrisée localement.
Pour éviter de configurer le GitLab Runner à la dernière minute, nous verrons dans l'article suivant comment l'installer (et pourquoi) sur un poste Windows utilisant Docker Desktop.
Naviguez entre les articlesBrowse through the articles
Installer et configurer un GitLab Runner local
Laissez-moi un commentaire

En postant un commentaire anonyme, vous adhérez automatiquement aux conditions d'utilisation du site.