Pourquoi GitLab est un bon choix
(whileforloop.com)- Présentation d’une expérience d’utilisation de GitLab sur le long terme, centrée sur la gestion de projets personnels et l’intégration CI/CD
- Au départ, la mise à disposition de dépôts privés gratuits constituait le principal avantage face à GitHub, puis le workflow s’est entièrement ancré avec le temps
- La fonctionnalité Container Registry est la plus utilisée, car elle permet de stocker des images sans compte Docker Hub distinct ni gestion de token
- Parmi les principaux points forts cités figurent les pipelines de GitLab CI basés sur des fichiers de configuration, les runners partagés gratuits et une documentation très riche
- En revanche, la lenteur de l’interface web et la surcharge fonctionnelle sont pointées comme inconvénients, et l’approche la plus efficace consiste à utiliser GitHub et GitLab en parallèle selon les usages
Contexte d’utilisation de GitLab
- L’utilisation a commencé à l’époque où GitHub faisait payer les dépôts privés, tandis que GitLab proposait des dépôts privés gratuits
- Cela permettait de gérer plusieurs projets expérimentaux sans les rendre publics
- Plus tard, GitHub a lui aussi adopté une politique gratuite, mais les pipelines CI, images Docker et scripts de déploiement étaient déjà construits autour de GitLab, rendant toute migration inutile
Fonction Docker Registry
- Tous les projets GitLab incluent par défaut un Container Registry
- Le flux est simple : construire l’image en local ou dans la CI, la pousser, puis la récupérer là où elle est nécessaire
- Aucun compte Docker Hub ni gestion de token distincts ne sont nécessaires, et il n’y a pas à s’inquiéter des limites de pull
- Pour des projets personnels, les fonctionnalités sont largement suffisantes, et la limite de capacité de 10 Go ne pose en pratique aucun problème
- Le nettoyage des anciens tags et le partage des layers permettent de conserver une bonne efficacité d’espace
Environnement CI/CD
- GitLab CI a mis en œuvre très tôt le concept de « CI basée sur un fichier de configuration »
- Il suffit d’ajouter un fichier
.gitlab-ci.ymlpour que le pipeline s’exécute automatiquement - La configuration étant versionnée, il est possible de suivre l’état des anciens pipelines
- Il suffit d’ajouter un fichier
- Le pipeline de base se compose de la construction d’image, du push et d’un déploiement optionnel
- L’étape de déploiement peut être contrôlée via un déclenchement manuel
- Les runners partagés sont gratuits mais lents ; si nécessaire, il est facile d’installer un runner auto-hébergé sur un VPS
- La documentation CI/CD est extrêmement vaste et, une fois les schémas assimilés, il devient efficace de gérer l’ensemble en copiant et réutilisant des configurations existantes
Points gênants
- La vitesse de l’interface web est lente, avec des temps d’attente lors du passage entre merge requests, pipelines et logs
- La situation semble s’être un peu améliorée récemment, mais cela reste plus lent que GitHub
- Il existe aussi un problème de surcharge fonctionnelle
- Suivi d’issues, wiki, package registry, security scanning et de nombreuses autres fonctions sont disponibles, mais le taux d’usage réel tourne autour de 10 %
- En revanche, cela offre aussi l’avantage potentiel de pouvoir exploiter des fonctions déjà intégrées en cas de besoin
Coût et workflow
- Environ 12 projets personnels sont exploités gratuitement, des projets actifs jusqu’aux expérimentations interrompues
- GitLab est utilisé comme espace de travail privé, tandis que GitHub sert d’espace de partage pour les projets publics
- GitHub convient à la collaboration et à la visibilité, GitLab à l’expérimentation et à la gestion de l’automatisation
- Une organisation reposant sur l’usage parallèle des deux plateformes permet de maintenir un bon équilibre et une bonne efficacité du workflow
3 commentaires
On dit souvent que GitLab est bon en CI/CD.
Mais moi, à cause des limitations du compte gratuit, même si le coréen est pris en charge, je me retrouve à préférer GitHub.
Forgejo et sa base, Gitea, me donnent aussi l'impression d'être une copie de GitHub, donc ça ne m'attire pas non plus.
Nous utilisons Gitea ; nous l’avons adopté parce que, avec cette image de "copie", la courbe d’apprentissage était faible.
Nous avons souvent eu des retours disant que GitLab avait trop de fonctionnalités, qu’il était difficile à utiliser et trop lourd..
Avis sur Hacker News
Les interlocuteurs du support client ont disparu et toutes les demandes doivent passer par l’équipe commerciale, tandis que la plupart des fonctionnalités sont réservées à la formule Ultimate, très chère
Les fonctionnalités qui ne relèvent pas de l’"IA" traînent les mêmes problèmes depuis des années sans être corrigées
Du coup, chaque fois que je reçois un e-mail commercial, je joue au jeu du « quand reverra-t-on le rythme de développement rapide d’autrefois ? »
Vers 2015~2020, je l’utilisais avec plaisir, mais toutes les fonctionnalités étaient rugueuses et l’accent était mis sur la checklist plutôt que sur la finition
C’était peut-être un choix inévitable pour une petite équipe qui voulait rivaliser avec de grands groupes
Dix ans plus tard, c’est toujours le cas, tandis que Gitea et Forgejo sont bien plus rapides, et cela devrait encore s’améliorer après la sortie de Go 1.26
La recherche d’issues est particulièrement lente, au point que je n’ai plus aucune envie de l’utiliser
En 2018, nous sommes passés de Bitbucket et Confluence à GitLab Cloud, et les produits Atlassian étaient bien plus lents et complexes
GitLab m’a semblé léger et rapide, et aujourd’hui encore tout fonctionne bien dans l’ensemble
J’ai récemment utilisé Jira Cloud, et c’était bien plus lent et pénible
C’est vraiment stupéfiant
La consommation électrique du serveur a baissé de 10 %, et GitLab avait trop de fonctionnalités inutiles, ce qui rendait l’UI étouffante
Forgejo est simple et permet de masquer des fonctions par projet
En revanche, il n’y a pas de mise à jour automatique, la finition est moindre et certaines fonctions ne marchent pas correctement
Je ne sais pas si c’est un thème Jekyll ou une création maison, mais la navigation elle-même était agréable
Je garde le CI, le suivi des issues, etc., dont j’ai besoin, mais l’interface se charge instantanément et il n’y a pas de fonctions superflues
Je préférais la syntaxe de GitLab CI, mais l’API de Forgejo est moins aboutie
Cela dit, on peut accéder directement à la base de données et s’en sortir avec des scripts personnalisés
Je lance un cluster Kubernetes, je relie Forgejo et Argo, puis je fais mes tests
Je ne sais pas s’il vaut mieux utiliser les ressources de Codeberg plutôt que celles de Microsoft
Le CI semble être géré par un projet appelé Woodpecker, et je suis curieux de la comparaison avec GitLab CI
GitLab, sans aller jusqu’à Gerrit, prend en charge les MR empilées, et on peut encore voir les commentaires après un force push
Je pense que la culture GitHub centrée sur les gros PR nuit à la productivité et à la culture de review
Les fonctions d’administration, comme la configuration de la synchronisation LDAP, pourraient être améliorées, mais la syntaxe CI/CD est dans l’ensemble pratique
Je l’ai utilisé tous les jours entre 2021 et 2024, au point de tenir un journal séparé des bugs
J’ai raconté cette expérience dans un commentaire précédent
Le simple issue tracker de GitHub est bien plus facile à utiliser
Les chefs de projet peuvent aimer GitLab, mais du point de vue de l’utilisateur, GitHub me paraît meilleur
Maintenant j’utilise GitHub, et c’est bien plus simple et efficace
Je déteste vraiment GitLab
Pour les images Docker, il n’y a qu’une limite par couche, et la taille totale peut être bien plus grande
Documentation liée : Storage Usage Quotas, Container Registry Issue
J’aimerais tenter d’y envoyer un REMUX de 70 Go d’Interstellar
Le schéma « j’essaie de faire quelque chose → erreur → recherche → découverte d’un bug report officiel vieux de 3 à 8 ans » se répète sans cesse
Beaucoup de fonctionnalités restent bloquées à un niveau de finition 80/20, et la vue MR est si lente qu’elle en devient pénible
J’en ai parlé dans un commentaire précédent
J’apprécie la possibilité d’intégrer les registres de paquets Maven, NPM et Python dans les pipelines CI
Mais il y a trop de fonctionnalités, et tous les écrans sont deux fois plus lents
Ensuite, nous sommes passés à Azure DevOps, qui est lent et a des quality gates médiocres
Le serveur de build a été remplacé par une VM, ce qui a ralenti les builds à cause des limites d’IOPS
J’aimerais revenir à GitLab et je serais prêt à contribuer à l’amélioration des performances