GitLab — principes de base, fonctionnalités et CI/CD

Qu'est-ce que GitLab ?

GitLab — est une plateforme DevOps open source complète sous licence MIT. Contrairement à GitHub, qui combine divers services via des intégrations, GitLab fournit un outil unique pour l'ensemble du cycle de vie du développement : de la gestion du code et de la révision du code au CI/CD, à la surveillance, à la sécurité et au déploiement. La plateforme ne nécessite pas de services tiers pour la plupart des tâches DevOps.

L'histoire de GitLab a commencé en 2011 en tant que projet interne de développeurs ukrainiens. La première version publique est sortie en septembre 2011, et en 2015, GitLab est devenu le premier projet sur GitLab.com, lançant l'hébergement cloud. En 2017, GitLab a réalisé un processus de migration douloureux mais instructif — le transfert de l'ensemble de l'infrastructure d'Azure vers Google Cloud, qui a été mené en direct et documenté dans une série d'articles.

L'architecture de GitLab se compose de trois composants principaux : GitLab Rails (application web en Ruby on Rails), GitLab Shell (gestion des opérations Git via SSH) et Gitaly (serveur gRPC pour l'accès aux données Git). Le CI/CD est assuré par GitLab Runner — une application séparée installée sur les serveurs de build qui exécute des jobs dans des environnements isolés (Docker, Kubernetes, VirtualBox).

GitLab CI/CD : pipelines et runners

GitLab CI/CD — est un système intégré d'intégration et de livraison continues qui constitue un avantage clé de la plateforme. Contrairement à GitHub Actions, GitLab CI/CD a été intégré à l'architecture dès le départ et ne nécessite pas de configuration séparée : chaque projet obtient automatiquement le CI/CD après l'ajout du fichier .gitlab-ci.yml à la racine du référentiel.

Un pipeline se compose d'étapes exécutées séquentiellement ou en parallèle : build → test → deploy. Chaque étape contient un ou plusieurs jobs exécutés sur des runners. Si un job dans une étape échoue, l'étape entière est marquée comme échouée et les étapes suivantes ne sont pas exécutées par défaut. Voici un exemple de pipeline pour un projet mobile :

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

GitLab Runner prend en charge plusieurs exécuteurs : Docker (recommandé), Kubernetes, SSH, VirtualBox et Parallels. L'option la plus populaire est l'exécuteur Docker, qui exécute chaque job dans un conteneur séparé. Un runner peut être enregistré comme spécifique à un projet ou comme partagé (shared) pour un groupe entier. GitLab.com fournit des runners partagés gratuits avec une limite de 2000 minutes par mois.

Fonctionnalités avancées du CI/CD

GitLab CI/CD prend en charge le déclenchement manuel (when: manual), le déclenchement différé (when: delayed), l'exécution parallèle (parallel: 5), la matrice, les pipelines dynamiques (child pipelines) et les pipelines multi-niveaux (parent-child). Cela permet de construire des scénarios complexes : par exemple, générer dynamiquement un pipeline pour chaque module dans un monorepo ou exécuter des builds parallèles pour différentes architectures Android (arm64, x86_64).

GitLab vs GitHub : différences clés

GitLab et GitHub — sont les deux principaux concurrents sur le marché des plateformes Git, mais leur philosophie et leur architecture diffèrent fondamentalement. GitHub mise sur la communauté ouverte, un écosystème d'intégrations et des fonctionnalités sociales (forks, étoiles). GitLab se concentre sur un cycle DevOps complet et fournit tous les outils prêts à l'emploi : de la planification à la surveillance.

La principale différence architecturale : GitLab — est une application monolithique unique que le développeur installe dans son intégralité. Toutes les fonctionnalités (CI/CD, Container Registry, Security Scanning, Pages) sont intégrées et fonctionnent immédiatement après l'installation. GitHub est une plateforme avec API où la plupart des fonctionnalités sont implémentées via l'intégration avec des services tiers : Travis CI, CircleCI, Jenkins, SonarQube. Le tableau ci-dessous compare les principales caractéristiques :

Le choix entre GitLab et GitHub dépend des besoins de l'équipe. Si la priorité est un déploiement rapide sans configuration et une communauté ouverte — choisissez GitHub. Si vous avez besoin d'un contrôle total de l'infrastructure, d'un hébergement auto-géré et d'une sécurité intégrée — GitLab est préférable. Selon une enquête Stack Overflow (2024), 90 % des développeurs utilisent GitHub, 33 % utilisent GitLab (souvent les deux plateformes simultanément).

Self-Managed GitLab : installation sur votre propre serveur

Self-Managed GitLab (anciennement On-Premises) permet d'installer la plateforme sur votre propre serveur et d'avoir un contrôle total sur les données, l'infrastructure et la disponibilité. Ceci est particulièrement important pour les organisations ayant des exigences de conformité : secteur financier, institutions gouvernementales, organismes médicaux où les données ne peuvent pas être stockées sur des serveurs tiers.

L'installation de GitLab est prise en charge sur Ubuntu, Debian, CentOS et via Docker. Le package officiel Omnibus comprend tous les composants : serveur web (NGINX), base de données (PostgreSQL), cache (Redis), gestionnaire Git (Gitaly) et processus d'arrière-plan. Configuration minimale requise : 4 Go de RAM et 2 CPU pour des équipes jusqu'à 100 personnes. Pour les installations importantes à forte charge, il est recommandé de répartir les composants sur des serveurs distincts.

# Installer GitLab CE sur Ubuntu via Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# Installation du paquet
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# Affichage du statut
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab n'a pas de limite de minutes CI/CD — tous les runners appartiennent à l'organisation et leur puissance n'est limitée que par votre propre matériel. Sont également disponibles la Géo-réplication pour les régions, les journaux d'audit, le blocage par IP et l'intégration avec les fournisseurs LDAP/SAML d'entreprise. GitLab publie des mises à jour chaque mois (le 22) avec de nouvelles fonctionnalités et des correctifs de sécurité.

Outils de sécurité intégrés de GitLab

La sécurité dans GitLab est intégrée au niveau de la plateforme et comprend plusieurs scanners qui fonctionnent à chaque étape du pipeline. SAST (Static Application Security Testing) analyse le code source à la recherche de vulnérabilités sans exécuter l'application, prenant en charge plus de 15 langages, dont Java, Kotlin, Swift, Python et JavaScript. DAST (Dynamic Application Security Testing) teste les applications web en cours d'exécution à la recherche de vulnérabilités de l'intérieur.

Outils supplémentaires : Container Scanning vérifie les images Docker pour les vulnérabilités dans les couches de base ; Dependency Scanning analyse les dépendances du projet et avertit des CVE connues ; Secret Detection trouve les clés API, mots de passe et tokens commités accidentellement ; Fuzz Testing effectue des tests automatisés avec des données invalides pour trouver des bugs non évidents. Tous les résultats d'analyse sont affichés dans un tableau de bord de sécurité unifié.

GitLab fournit également des outils de Conformité pour répondre aux exigences réglementaires. Le tableau de bord de conformité affiche l'état de conformité de tous les projets, les événements d'audit enregistrent chaque action de l'administrateur et du développeur, et les cadres de conformité permettent d'appliquer obligatoirement des politiques de configuration pour des groupes spécifiques de projets. Cela fait de GitLab un choix populaire dans les environnements d'entreprise aux exigences de sécurité strictes.

Registre de conteneurs et Dependency Proxy

GitLab Container Registry — est un registre Docker intégré au CI/CD. Après avoir construit une image Docker dans un pipeline, elle peut être immédiatement publiée dans le registre à l'aide des variables d'environnement CI_REGISTRY et CI_REGISTRY_USER. Le registre prend en charge la mise en cache pull-through, l'étiquetage, les politiques de nettoyage et l'analyse des vulnérabilités directement dans le registre.

Dependency Proxy — un mécanisme de mise en cache pour les conteneurs et images provenant de registres externes (Docker Hub, Quay, GCR). Lorsqu'un pipeline demande une image comme ubuntu:latest, GitLab vérifie d'abord son cache — si l'image est déjà téléchargée, elle n'est pas récupérée à nouveau. Cela réduit la charge sur les registres externes, accélère les pipelines et protège contre les limites de débit de Docker Hub.

Pour les développeurs mobiles, GitLab fournit GitLab Pages pour héberger la documentation et les rapports de test. Après l'exécution des tests, les artefacts (rapports HTML, captures d'écran, journaux) peuvent être publiés en tant que Pages et un lien peut être partagé avec l'équipe QA. C'est plus pratique que de télécharger des rapports dans un stockage cloud car tout reste au sein du même projet GitLab.

API GitLab et Webhooks

L'API GitLab (REST et GraphQL) donne accès à toutes les ressources de la plateforme : projets, utilisateurs, pipelines, Merge Requests, registre. L'API est utilisée pour l'automatisation : créer un projet à partir d'un modèle, assigner un réviseur, obtenir le statut d'un pipeline. Les Webhooks permettent d'envoyer des notifications HTTP à des systèmes externes lors d'événements : push, merge, création d'Issue. Les Webhooks s'intègrent avec Mattermost, Slack, Telegram et les systèmes de surveillance internes.

GitLab Pages pour la documentation mobile

GitLab Pages publie automatiquement des sites web statiques à partir d'un référentiel. Pour les projets mobiles, Pages est pratique pour héberger la documentation d'API, les rapports de couverture de test et les résultats d'analyse lint. La publication se fait automatiquement après un pipeline réussi — il suffit d'ajouter une étape de déploiement avec publication dans Pages. Le résultat est disponible à l'adresse https://namespace.gitlab.io/project-name.