GitLab

En voici un d’outil ! Très connu par nos ami(e)s informaticien(ne)s mais pas que. Le sujet peut paraître banal ou « trop facile », et c’est vrai qu’il existe un très grand nombre d’articles sur le sujet. Toutefois, malgré les dix ans d’expérience sur le terrain, je me rends compte que les jeunes arrivants dans le milieu ne maîtrisent toujours pas Git, et ne savent pas ce qu’est GitLab…

Je dois avouer que je suis assez surprise de voir que certaines écoles n’enseignent toujours pas les bases de cet outil, qui fait pourtant partie du cœur du métier.

C’est pourquoi j’ai envie de partager mes connaissances, acquises via la veille technologique, mes recherches et mes tests, mais surtout les nombreuses discussions et débats avec mes collègues de travail pour savoir quelle est la meilleure méthode d’utilisation selon chacun.

Ma façon de voir les choses n’est en aucun cas une référence. C’est simplement la mienne et elle continuera certainement à évoluer selon mes activités et les différents projets sur lesquels je donnerai un coup de main. Je partage simplement ici quelques savoir-faires que je pense être intéressants.

C’est quoi GitLab ?

GitLab, c’est un de mes outils préférés ! Il est basé sur Git et permet donc de faire de la gestion de version mais pas seulement, d’où la présence de « Lab » !

Et c’est là que tout devient ultra intéressant. Cette partie Lab englobe tellement de choses que GitLab à lui seul permet de répondre à un grand nombre de besoin DevOps.

Dans les grandes lignes, il est bon de savoir que Gitlab permet de faire du ticketing, de la planification, des tests automatiques, du déploiement automatique, de l’opération, de la documentation et j’en passe ! Avec GitLab, plein de choses sont possibles sans avoir à changer constamment d’outils.

J’ai souvent poussé l’intégration et l’utilisation de GitLab dans les équipes qui cherchaient à optimiser leur infrastructure mais il faut noter que ça n’est pas toujours possible. A mes yeux, c’est là (entre autres) que se distinguent les ingénieurs : dans leur capacité à s’adapter. C’est donc important de garder en tête que même si GitLab est capable de faire de grandes choses, ses concurrents existent et sont souvent déjà bien implémentés dans les infra existantes. Pour ma part, j’ai eu l’opportunité de travailler sur d’autres outils comme JIRA, Confluence ou Jenkins. Et c’était tout aussi appréciable !

Points forts / Points faibles

Pourquoi (ou pourquoi ne pas) utiliser GitLab ? Là encore, tout dépend de plein de choses : l’opinion de tous, les compétences et connaissances des utilisateurs, les contraintes du projet, le budget, le planning… Bref, rien de mieux qu’un trade-off pour comparer différents outils.

Dans cette partie, je vais simplement énoncer ce que j’ai trouvé intéressant avec GitLab et là où j’ai galéré ou dû gérer ma frustration…

GitLab, c’est cool

GitLab, c’est un outil « tout en un« , facile à utiliser et plutôt intuitif (tout le monde n’est pas d’accord avec moi). Mais j’aime particulièrement ne pas avoir à gérer les différents flux entre différents outils et ne pas avoir à naviguer entre 150 onglets dans mon navigateur (ceux qui me connaissent savent que je m’en sors déjà difficilement avec plus de cinq onglets actifs). Tout est lié ! Ainsi, en ouvrant un ticket, il est possible, grâce à l’IHM, de créer une nouvelle branche associée, voir l’historique de l’activité, faire une merge request, changer le statut, etc.

Grâce à ses dahsboards et graphs, il est possible de configurer une vue spécifique pour toujours veiller sur les activités passées ou en cours.

Bref, en creusant, GitLab permet de gérer le cycle de vie complet de son projet, en passant par des vérifications du code et l’intégration de la sécurité.

Mais comme tout logiciel digne de ce nom, il comporte également son lot de désobligeance…

Parfois, c’est moins cool…

J’ai déjà entendu dire que GitLab était une « usine à gaz ». Entendez par-là : outil trop lourd et trop complexe. Et ce n’est pas toujours faux ! Pour autant, je modère mon propos.

Beaucoup pensent que GitLab n’est pas adapté aux petits projets. Je ne suis pas tout à fait d’accord. Peu importe qu’on souhaite utiliser sa partie ticketing, le CI/CD ou autre chose, GitLab reste adapté et largement utilisable. De plus, un petit projet peut vite grossir et à ce moment, on peut être content d’avoir un outil déjà tout prêt pour avancer.

Par contre, son déploiement dans une infra est quelque peu… gourmande et fastidieuse. Et c’est peut-être là que ça pêche. Avoir un GitLab fonctionnel et performant nécessite de lire la documentation officielle, de faire des tests, de prendre des notes et de s’accrocher. Et lorsqu’on se lance dans ce genre de choses, on note qu’il faut également penser à la maintenance, aux migrations, à la sécurité… A tout plein de choses quoi ! Il est donc nécessaire d’avoir un minimum de maîtrise et de connaissances avant de se lancer !

Un autre point assez usant est que GitLab n’est pas utilisé tant que ça dans certaines organisations. Il est plus jeune que certains de ses concurrents et la migration demande du temps pour le déploiement, l’adaptation et les tests de non régression.

Prérequis

Avant de se lancer tête baissée dans GitLab, il faut s’assurer de connaître quelques bases. A mon sens, il est essentiel de :

• Comprendre Git : les commandes élémentaires comme « git clone », « git add », « git commit », « git push », et « git pull ».
• Avoir un minimum de notions en ligne de commande (bash, zsh, ou autre) : beaucoup de tâches quotidiennes passent par là.
• Savoir ce qu’est un workflow Git (Git flow, GitHub flow ou autre).
• Connaître les concepts de branche, commit, merge et rebase.
• Pour utiliser GitLab CI/CD, quelques bases en YAML sont aussi un gros plus.

Avec ça, vous serez déjà bien armé pour vous lancer !

Utilisation de GitLab

GitLab peut s’utiliser de deux façons principales :

• Via l’interface web (IHM) : pratique pour le ticketing, les merge requests, la visualisation des pipelines, etc.
• En ligne de commande : indispensable pour interagir avec le dépôt Git, créer et mettre à jour vos branches, etc.

En pratique, le quotidien se résue souvent à :

• Créer une branche depuis l’interface ou en ligne de commande
• Développer ses modifications localement.
• Committer et pusher la branche.
• Créer une merge request pour soumettre son travail.
• Gérer la revue de code via l’interface.
• Fusionner la branche après validation.

Issues

Les issues sont un pilier dans GitLab. C’est grâce à elles que vous pouvez :

• Décrire des tâches à réaliser,
• Suivre des bugs,
• Proposer des évolutions,
• Assigner des tâches aux membres de l’équipe,
• Relier facilement une issue à une merge ou un commit.

Les issues sont extrêmement pratiques car elles centralisent la discussion, la documentation et les décisions sur un sujet donné.

Merge requests

La merge request (MR) est l’endroit où la magie opère. C’est là que :

• Vous proposez vos changements pour qu’ils soient intégrés dans la branche principale.
• Vous déclenchez la revue de code par vos collègues.
• Vous pouvez configurer l’outil pour que les tests CI/CD associés se lancent automatiquement.
• La discussion autour des changements peut se faire, ligne par ligne si besoin.
• Une fois approuvée, vous pouvez fusionner la branche en un clic (ou avec un merge automatique si les conditions sont remplies).

Milestones

Les milestones (jalons) servent à regrouper plusieurs issues et merge requests sous un objectif commun, comme :

• Une version précise (ex: v1.0.0),
• Une deadline importante (fin de sprint, livraison à un client…).

GitLab CI/CD

Comme je l’ai déjà dit, l’un des atouts majeures de GitLab, c’est son système de CI/CD intégré. Plus besoin d’outils externes comme Jenkins ou CircleCI pour gérer vos pipelines : tout est centralisé au même endroit. La configuration se fait via un simple fichier .gitlab-ci.yml placé à la racine du projet. Dans ce fichier, vous définissez vos jobs (étapes de build, tests, déploiements…) et vos stages.

Ci-dessous, voici un exemple minimaliste pour vous donner une idée :

stages:
  - build
  - test

build_job:
  stage: build
  script:
    - echo "Building the project..."

test_job:
  stage: test
  script:
    - echo "Running tests..."

A chaque commit ou MR, GitLab déclenche ces jobs selon les conditions que vous avez préalablement définies. Cela permet d’automatiser la vérification du code, le packaging, le déploiement, et même la génération de documentation. Grâce à la puissance de GitLab CI/CD, vous pouvez aussi déployer sur des environnements comme Kubernetes ou Docker Swarm de façon fluide.

Runners

Pour exécuter vos jobs CI/CD, GitLab s’appuie sur des runners : des machines (physiques ou virtuelles) qui récupèrent le code et lancent vos scripts. GitLab propose deux types principaux de runners :

• Runners partagés : ils sont mis à disposition directement par GitLab.com pour les projets hébergés sur les SaaS. C’est simple, rapide et pratique pour démarrer, mais vous partagez les ressources avec d’autres utilisateurs, ce qui peut entraîner des files d’attente et moins de contrôle.
• Runners auto-hébergés : vous pouvez installer vos propres runners sur vos serveurs ou VMs. Cela vous offre un contrôle total sur les ressources, la configuration et la sécurité. Idéal pour les entreprises qui veulent garder la main sur l’exécution des pipelines ou pour les besoins spécifiques (ex : runner Windows, GPU, etc.).

La configuration est relativement simple, il suffit d’installer le binaire GitLab Runner, de l’enregistrer auprès de votre instance GitLab et de choisir l’exécuteur (shell, Docker, Kubernetes, etc.).

Sécurité et DevSecOps

GitLab ne se limite pas à l’automatisation du code : il intègre aussi des fonctionnalités avancées pour la sécurité. Grâce à GitLab Ultimate (et en partie aux offres Premium et Free), vous pouvez activer des analyses automatiques sur votre code, comme :

• SAST (Static Application Security Testing) : analyse du code source pour détecter les vulnérabilités.
• DAST (Dynamic Application Security Testing) : tests de sécurité sur les applications en cours d’exécution.
• Dependency Scanning : détection de dépendances vulnérables dans vos packages.
• Container Scanning : analyse des images Docker pour y repérer des failles connues.

Ces outils vous permettent d’intégrer la sécurité dans vos pipelines CO/CD pour adopter une approche DevSecOps, où la sécurité fait partie intégrante du cycle de développement, sans attendre la fin du projet. Résultat : moins de surprises en production !

Personnalisation et intégrations

GitLab est très flexible et peut s’adapter à vos besoins grâce à de nombreuses possibilités de personnalisation :

• Webhooks : permet de notifier d’autres outils ou systèmes externes lors d’évènements comme un push, une MR ou un pipeline. Pratique pour envoyer des messages sur Slack, déclencher un job Jenkins ou appeler un microservice.
• Intégrations tierces : GitLab propose des intégrations natives avec des outils comme Slack, Mattermost, Jira, Microsoft Teams, Prometheus ou Sentry. De quoi améliorer la collaboration, la visibilité et le suivi des incidents.
• API REST et GraphQL : GitLab expose une API très complète pour automatiser la gestion des projets, des issues, des pipelines, etc. Vous pouvez écrire vos propres scripts pour, par exemple, créer automatiquement des tickets, générer des rapports ou synchroniser des informations avec un ERP.

Ces capacités en font un véritable hub central pour votre écosystème DevOps.

Exemple de workflow

Pour rendre tout ça comcret, voici un petit exemple que j’utilise souvent :

1. Une issue est créée : « Corriger le bug de connexion ».
2. Je crée une branche directement depuis l’issue dans GitLab (super pratique) : fix/login-bug.
3. Je développe localement, puis je push mes changements.
4. GitLab détecte automatiquement le lien entre la branche et l’issue grâce aux conventions de nommage ou à un mot-clé dans le commit (ex : Closes #42).
5. Je crée une merge request en la liant à l’issue.
6. Les tests CI/CD se déclenchent.
7. Un collègue fait la revue de code.
8. Une fois la MR approuvée et les tests passés, on fusionne.
9. L’issue se ferme automatiquement et la milestone (ex: « Sprint 5 ») avance.

Et voilà ! Avec ce genre de workflow, votre équipe gagne en efficacité, en traçabilité et en qualité !

Bonnes pratiques

Pour tirer le meilleur de GitLab, voici quelques bonnes pratiques qui fond souvent la différence :

• Adopter un workflow clair : que vous utilisiez Git flow, GitHub flow ou un modèle maison, assurez-vous que tout le monde soit aligné. Cela évite la confusion sur le nommage des branches ou les étapes de validation.
• Utiliser des labels et templates : des labels clairs permettent de filtrer efficacement les issues et MRs. Les templates d’issus et de MR garantissent que chacun fournisse les informations essentielles dès le départ.
• Gérer les milestones : regroupez vos tâches et MR sous des jalons pour suivre l’avancement de vos releases ou sprints.
• Configurer les protected branches : évitez qu’un développeur pousse directement sur « main » ou « production » en restreignant les droits d’écriture. Cela force le passage par les merge requests.
• Automatiser les tests et vérifications : un pipeline qui test automatiquement le code, la sécurité et le style garantit la qualité et réduit les régressions.
• Suivre la couverture et la qualité du code : GitLab peut afficher la couverture des tests ou les résultats de linters directement dans les MRs.

En appliquant ces quelques conseils, je pense qu’on peut exploiter GitLab à son plein potentiel et améliorer durablement vos processus de développement.

Conclusion

Pour résumer, GitLab est un outil puissant qui centralise la gestion de projet, l’intégration continue et la sécurité, le tout dans un seul espace. En l’adoptant et en suivant de bonnes pratiques, vous pouvez considérablement améliorer la qualité, la traçabilité et la collaboration au sein de vos équipes.

Surtout, il faut se souvenir d’un point très important : GitLab est un outil puissant, mais ce n’est qu’un outil. GitLab n’est efficace que s’il s’intègre dans un processus clair et compris de tous. Alors, n’hésitez pas à expérimenter, à explorer ses fonctionnalités et à adapter son utilisation à vos besoins : c’est en pratiquant que vous en tirerez le meilleur !