- 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.yml pour que le pipeline s’exécute automatiquement
- La configuration étant versionnée, il est possible de suivre l’état des anciens pipelines
- 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
Aucun commentaire pour le moment.