cClaude.rocks ☕ Le blog

GitLab est un logiciel libre de forge basé sur git proposant les fonctionnalités de wiki, un système de suivi des bugs, un système d’intégration continue et de livraison continue. GitLab est développé par GitLab Inc. qui à fait son introduction en bourse en octobre 2021, atteignant l’objectif que c’était fixé les initiateurs du projet depuis le début.

Cette trajectoire vers un financement boursier à de fortes implications sur le choix des fonctionnalités et des corrections de bug qui sont traitées.

GitLab s’est peu à peu orienté vers une solution clé en main prenant en charge la chaîne de développement et de déploiement. En brisant la complexité de la gestion de version, la solution est devenue simpliste, elle encourage de nombreuses mauvaises pratiques qui ont pour effet d’anéantir les progrès dans ce domaine que permet git.

Le parcours du développement de GitLab à favoriser l’arrivée de nouvelles fonctionnalités au détriment de la stabilisation de l’existant ceci pour obtenir de nouveaux clients.

De nombreuses fonctionnalités, en particulier sur la gestion des versions, ne fonctionnent pas correctement. Pire, j’ai été témoin de demande d’évolutions qui sont des anti-modèles, les arrivants étant généralement des personnes qui ne connaissaient pas git et ces avantages mais qui souhaitait retrouver leurs réflexes venant de svn, voir de système de gestion de version plus ancien. Voir Anti-pattern et Allow disabling "Squash and merge" for a project. Bref, GitLab encourage l’utilisation de git à la manière de svn…

GitLab a su séduire ces utilisateurs en leurs donnant des fonctionnalités qu’ils pensaient avoir besoin du fait de leur manque de connaissances sur le système de gestion de version git. Cela marquera d’ailleurs longtemps, je pense, le développement logiciel, les « simplifications » proposées par GitLab permettant de gagner du temps, au mépris de la qualité, plus précisément au mépris du suivi des changements. Mais c’est très conforme à notre monde où le gain de productivité est prioritaire sur tout autre considération.

Le nombre de problèmes ouverts (« open issues ») est alarmant, pourtant GitLab applique des règles de fermeture automatiques drastiques, le moindre bug remonté, qui n’a pas une description claire de la manière de le reproduire et qui n’est pas rapidement confirmé est fermé. J’ai fait plusieurs rapports de bugs et seul ceux que j’ai fait au titre d’un client « Premium » ont été prises en comptes, et que peu de ces bugs sont aujourd’hui résolus.

GitLab sur la plateforme.

Lorsque j’ai choisi GitLab pour gérer la plateforme, l’application nécessitait 1 Go de RAM et 1 Go de swap. C’était déjà beaucoup, mais un Raspberry PI 3 pouvait faire l’affaire.

Aujourd’hui GitLab nécessite au minimum 8 Go de RAM… C’est, de loin, l’outil le plus gourmand en ressources dans le domaine.

D’ailleurs au prix des VM (Ordinateur virtuel que les entreprises louent dans le « cloud »), cela me semble remettre en cause l’intérêt de GitLab, autant prendre une solution chez Micro$oft (Git-hub) ou chez Atlassian (Bitbucket). Bref, vu le coût de la VM, dans tous les cas, il est raisonnable de toujours payer à minima une licence Premium.

Pour ma part, je cherche une solution auto-hébergée et qui tourne sur une machine basse consommation ; GitLab ne rentre plus dans ce cahier des charges. Cependant, j’ai l’ensemble de ma configuration est aujourd’hui basée sur GitLab, m’en passer à un coût non négligeable.

Le GitLab a planté…

Bon, en soit, même si ce n’est pas normal, je ne peux pas tout mettre sur le dos de GitLab qui tournais sur une machine avec 4 Go de RAM et probablement pas assez de swap…

Cependant, ce fut l’occasion de découvrir que les sauvegardes ne fonctionnaient pas toujours. Je creuserais peut-être ce point, car je suis presque certain d’arriver à le reproduire.

Autre surprise, l’installation de GitLab sur Raspberry Pi OS Bullseye ne fonctionne pas…

De manière générale, ma confiance dans GitLab est aujourd’hui pas très grande, et je suis même inquiet pour son avenir, car j’ai vraiment l’impression que les développeurs de GitLab ne maîtrisent plus vraiment le code de ce monstre.

Mais une leçon qui se confirme concernant GitLab, ce n’est pas une application qui tourne toute seule dans son coin, elle demande une équipe pour l’administrer, c’est un travail plutôt lourd et très incompatible avec ce qu’attentent les entreprises comme les particuliers d’un tel outil.

Remplacement de GitLab

J’ai du en urgence remonter un serveur git à l’aide de Gitea, un logiciel que j’avais également évalué lors du choix initial et j’ai été très agréablement surpris de son évolution.

J’ai finalement écrit des scripts permettant de remonter une sauvegarde GitLab dans Gitea. Actuellement ces scripts prennent en charge les dépôts de sources, les wikis. Ils transforment les groupes GitLab en organisations Gitea, prend en compte quelques cas particuliers.

Pour la suite, je ne sais pas trop, il me faut un outil d’intégration et de déploiement (« CI/CD ») ; je n’écarte pas l’idée de remonter un GitLab pour cela, puisque cela m’éviterait un travail considérable et périlleux sur le code de déploiement.

Liens

• Présentation de GitLab sur Wikipédia
• Problèmes ouvert de Gitlab (« issues ») :
  • Provide packages for Raspberry Pi OS Bullseye
  • MR diff/changes view shows old commits/changes ouvert en 2016, fermée à la faveur d’une évolution 🧮 Use merge refs for diffs toujours ouverte à ce jour. En gros, cela veut dire qu’il n’est pas possible de faire confiance à un simple diff avec GitLab.
• GitLab a pris conscience en 2019 qu’ils avaient des problèmes de consommation de mémoire anormal : Why we created a Memory team at GitLab mais pour l’instant, il n’y a aucune amélioration, bien au contraire.
• Les systèmes de gestion de version, une présentation de l’université d’Orléans.
• Qu’est qui ne va plus avec Subversion ? un article de 2011…
• Le site de Gitea

ᦿ